Vulnerability scanning intelligent prioritization method and system based on asset criticality

Abstract

This application provides a method and system for intelligent priority ranking of vulnerability scanning based on asset importance, relating to the field of network security technology. The method includes: acquiring asset nodes, a vulnerability list, and a call chain to construct a business call topology and extract standard traffic trajectories; calculating vulnerability diffusion rates based on the number of vulnerabilities and downlinks to generate initial risk weights, and marking nodes with multiple upstream calls as risk convergence nodes; intercepting communication data packets pointing to risk convergence nodes to draw real-time traffic trajectories and extracting trajectory deviation features; injecting decoy tags into protocol headers to encapsulate them into probe blocks and allowing them to be passed downstream, tracing the flow path to extract the threat diffusion radius; and combining abnormal call intent and lateral movement range to correct and weight the initial risk weights to determine vulnerability scanning priorities, thereby improving the accuracy of vulnerability scanning.

Description

Technical Field

[0001] This application relates to the field of cybersecurity technology, and in particular to a method and system for intelligent priority ranking of vulnerability scanning based on asset importance. Background Technology

[0002] With the widespread application of microservice architecture in enterprise-level business systems, a single business is often supported by a large number of service instances working together. Asset nodes form complex dependency topologies through frequent remote calls. When an upstream node has an exploitable security vulnerability, attacks often spread horizontally along the call chain to downstream services, causing serious consequences such as leakage of core business data or service unavailability.

[0003] Current vulnerability scanning methods often proceed item by item based on an asset list, with the scanning order typically based on asset number or network segment order. This approach fails to adequately consider the actual call dependencies of microservices, resulting in scanning resources being distributed across all nodes. Nodes that truly carry critical business operations and are on the attack path are not given priority. The sorting is based solely on the number of vulnerabilities or a single risk rating, making it difficult to identify highly sensitive nodes that have few vulnerabilities but are located at the call hub.

[0004] Some solutions attempt to introduce static topology weights to adjust the scanning order, using node out-degree or in-degree as a priority reference. However, they still rely mainly on static attributes and cannot capture the attacker's true probing intent and traffic anomalies during runtime. When attackers penetrate core nodes through carefully crafted requests, there is a significant deviation between the priority given by static weights and the actual threat distribution, posing challenges to the overall timeliness and accuracy of security protection. Summary of the Invention

[0005] In view of this, the purpose of this application is to overcome the shortcomings discussed in the background section and provide an intelligent priority ranking method for vulnerability scanning based on asset importance. This method can combine the actual microservice call structure with runtime traffic anomalies and threat propagation information, enabling asset nodes located on core attack paths to be identified and dealt with first, thereby improving the utilization efficiency of scanning resources and the accuracy of the overall security response. To address the aforementioned technical problems, in a first aspect, this application provides a vulnerability scanning intelligent priority ranking method based on asset importance, comprising: Obtain the asset nodes, vulnerability list, and call chain of the microservice cluster to construct the business call topology, and extract the standard traffic trajectory of the asset nodes; Traverse along the call dependency direction in the business call topology, calculate the vulnerability spread rate based on the number of vulnerabilities and the number of downlink call links, generate the initial risk weight of the asset node, and mark the asset node with multiple upstream calls as risk intersection node to locate the core attack path; Intercepting communication data packets directed to the risk intersection node, drawing real-time traffic trajectories, and extracting trajectory deviation features from the standard traffic trajectory to map abnormal call intentions targeting the core attack path; The decoy tag is injected into the protocol header of the communication data packet and encapsulated as a probe block, and then allowed to pass downstream of the risk intersection node; The threat spread radius is extracted by tracing the flow path of the probe block in order to quantify the potential lateral movement range caused by the abnormal invocation intent; Combining the abnormal call intent and the lateral movement range, the initial risk weights of the risk intersection nodes on the core attack path are modified and weighted to calculate the modified risk weights. The non-intersection nodes retain the initial risk weights, and the vulnerability scanning priority of all asset nodes is determined according to the order of weight values ​​from high to low.

[0006] Optionally, extracting the standard traffic trajectory of the asset node includes: Collect the timing sequence of business requests triggered between the asset nodes and the response latency parameters during a continuous time period when the asset nodes are in a non-attack state; The request instruction types in the business request time sequence are classified and statistically analyzed to determine the triggering order of the request instruction types. Based on the triggering order and the response delay parameter, a trigger envelope profile for each request instruction type is constructed within a multi-dimensional time window. The trigger envelope profile is used as the standard traffic trajectory of the asset node.

[0007] Optionally, the step of calculating the vulnerability spread rate based on the number of vulnerabilities and the downlink volume to generate the initial risk weight of the asset node includes: Read the risk rating scores from the vulnerability list associated with the asset node, and add up the risk rating scores to obtain the basic vulnerability score; The total number of outgoing connections from the asset node to other downstream asset nodes in the business call topology is counted, and the total number of outgoing connections is used as the downlink quantity. The vulnerability spread rate is obtained by multiplying the basic vulnerability score with the downlink quantity. The initial risk weight of the asset node is obtained by multiplying the preset business carrying importance parameter with the vulnerability diffusion rate.

[0008] Optionally, marking asset nodes with multiple upstream calls as risk convergence nodes includes: Backtrack in reverse along the call dependency direction of the business call topology to count the number of independent call chains that directly point to the same asset node; When the number of independent call chains is greater than or equal to a preset call path threshold, it is determined that the asset node accepts multi-source business requests, and the asset node that is determined to accept multi-source business requests is marked as a risk convergence node.

[0009] Optionally, the step of intercepting communication data packets directed to the risk convergence node, drawing a real-time traffic trajectory, and extracting trajectory deviation features from the standard traffic trajectory includes: The intercepted communication data packets are analyzed to obtain the payload instruction set and arrival time interval, and a real-time traffic trajectory is drawn for the risk intersection node based on the payload instruction set and arrival time interval. The real-time traffic trajectory is projected onto its corresponding multi-dimensional time window, and the coordinate displacement difference between the real-time traffic trajectory and the trigger envelope contour of the standard traffic trajectory is obtained by comparison. The frequency of sudden increases in the coordinate displacement difference within a continuous period is statistically analyzed, and the frequency of sudden increases and the coordinate displacement difference are used as trajectory deviation features.

[0010] Optionally, the step of encapsulating the protocol header of the communication data packet injected with the decoy tag into a probe block includes: Read the context metadata control area of ​​the communication data packet to bypass the business logic load area of ​​the communication data packet; Add a custom tracking extension field within the context metadata control area, and write the trapping tag into the custom tracking extension field; The control information of the communication data packets written to the decoy tag is updated by verification and recalculation to form a probe block.

[0011] Optionally, the step of tracing the flow path of the probe block to extract the threat diffusion radius includes: Capture the forwarded data stream carrying custom tracing extension fields within the microservice cluster; Record the total number of hop nodes of the asset nodes through which the forwarded data stream passes, and the initial risk weight of each asset node along the path; The total number of jump nodes is multiplied by the sum of the initial risk weights of each of the asset nodes along the path, and the product is used as the threat diffusion radius.

[0012] Optionally, the step of combining the abnormal call intent and the lateral movement range to perform a corrected weighted calculation on the initial risk weights of the risk intersection nodes on the core attack path, and calculating the corrected risk weights, includes: The trajectory deviation features mapped by the abnormal call intent are transformed into deviation penalty factors; The threat spread radius quantified by the lateral movement range is converted into a risk amplification index; Using the initial risk weight of the risk intersection node as the base, and the risk amplification index as the power, an exponential operation is performed. The result of the exponential operation is then multiplied by the deviation penalty factor to obtain the corrected risk weight of the risk intersection node.

[0013] Optionally, after determining the vulnerability scanning priority of all the asset nodes according to the weight values ​​from high to low, the method further includes: According to the sorting result of vulnerability scanning priority from high to low, scan concurrent thread resources are allocated to all the asset nodes in sequence; Extract the first asset node that ranks within the priority set ratio, and issue a penetration scan command containing a depth detection script to the extracted first asset node; Extract the second asset node that is outside the priority setting ratio, and issue a comparison scan command including port detection to the extracted second asset node.

[0014] Secondly, this application provides an intelligent priority ranking system for vulnerability scanning based on asset importance, comprising: The acquisition module is used to acquire the asset nodes, vulnerability list, and call chain of the microservice cluster to construct the business call topology, and to extract the standard traffic trajectory of the asset nodes; The calculation module is used to traverse along the call dependency direction in the business call topology, calculate the vulnerability spread rate based on the number of vulnerabilities and the number of downlink call links, generate the initial risk weight of the asset node, and mark the asset node with multiple upstream calls as risk intersection node to locate the core attack path. The extraction module is used to intercept communication data packets pointing to the risk intersection node, draw real-time traffic trajectories, and extract trajectory deviation features from the standard traffic trajectory to map abnormal call intentions targeting the core attack path. An injection module is used to encapsulate the protocol header of the communication data packet injected with the decoy tag into a probe block and allow it to pass downstream of the risk intersection node; The quantization module is used to track the flow path of the probe block to extract the threat diffusion radius, so as to quantify the potential lateral movement range caused by the abnormal calling intent; The correction module is used to combine the abnormal call intent and the lateral movement range to perform a corrected weighted calculation on the initial risk weight of the risk intersection nodes on the core attack path, and calculate the corrected risk weight. The non-intersection nodes retain the initial risk weight, and the vulnerability scanning priority of all asset nodes is determined according to the order of the weight values ​​from high to low.

[0015] This application provides an intelligent priority ranking method for vulnerability scanning based on asset importance. The method includes: acquiring asset nodes, vulnerability lists, and call chains of a microservice cluster to construct a business call topology, and extracting standard traffic trajectories of the asset nodes; traversing along the call dependency direction in the business call topology, calculating the vulnerability diffusion rate based on the number of vulnerabilities and the number of downlink call links, generating initial risk weights for the asset nodes, and marking asset nodes with multiple upstream calls as risk convergence nodes to locate core attack paths; intercepting communication data packets pointing to the risk convergence nodes, drawing real-time traffic trajectories, and extracting trajectory deviation features from the standard traffic trajectories. The system maps abnormal invocation intents targeting the core attack path; it encapsulates the protocol header of the communication data packet with a decoy tag into a probe block and allows it to pass downstream of the risk convergence node; it tracks the flow path of the probe block to extract the threat diffusion radius, thereby quantifying the potential lateral movement range caused by the abnormal invocation intent; and it performs a corrected weighted calculation on the initial risk weights of the risk convergence nodes on the core attack path by combining the abnormal invocation intents with the lateral movement range, thereby calculating a corrected risk weight. Non-convergence nodes retain the initial risk weights, and the vulnerability scanning priority of all asset nodes is determined according to the order of weight values ​​from high to low.

[0016] The method provided in this application integrates information from three aspects: business call topology, runtime traffic anomalies, and threat lateral spread. This enables asset nodes located on the core attack path to be identified first and assigned higher scanning intensity. It overcomes the accuracy problem of the prioritization method based on static attributes in the existing technology, improves the utilization efficiency of vulnerability scanning resources, enhances the real-time perception capability of the core attack path, and reduces the risk of critical business being subjected to lateral penetration. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1This application discloses a schematic diagram of an intelligent priority ranking system architecture for vulnerability scanning based on asset importance. Figure 2 This application discloses a flowchart of an intelligent priority ranking method for vulnerability scanning based on asset importance. Figure 3 This is a schematic diagram of a service call topology network disclosed in this application; Figure 4 This is a schematic diagram of a real-time traffic trajectory drawing process disclosed in this application; Figure 5 This is a schematic diagram comparing the coordinate deviations of a standard traffic trajectory and a real-time traffic trajectory disclosed in this application. Figure 6 This application discloses a flowchart of a detector block encapsulation and threat propagation tracking process. Figure 7 This is a schematic diagram of a modified risk weight calculation logic disclosed in this application; Figure 8 This application discloses a flowchart for vulnerability scanning priority ranking and resource allocation. Detailed Implementation

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

[0020] Current vulnerability scanning technologies often proceed item by item based on an asset list, distributing scanning resources evenly across all nodes, while nodes that actually carry critical business operations do not receive priority. Although some improvement solutions introduce static topology weights, they still cannot capture the attacker's true probing intent and traffic anomalies during runtime, resulting in insufficient scanning accuracy.

[0021] To overcome the aforementioned technical problems, this application discloses an intelligent priority ranking method for vulnerability scanning based on asset importance, which can be applied to a microservice environment to improve the utilization efficiency of vulnerability scanning resources, enhance the real-time perception of core attack paths, and reduce the risk of critical business operations being subjected to lateral penetration.

[0022] See Figure 1 As shown, the vulnerability scanning intelligent priority ranking system architecture based on asset importance provided in this application includes a security management platform 11, a traffic collection agent 12, a service mesh component 13, a vulnerability scanning engine 14, and a microservice cluster 15, wherein the microservice cluster 15 contains several asset nodes 151.

[0023] The security management platform 11 serves as the overall scheduling center and establishes data channels with the traffic collection agent 12, the vulnerability scanning engine 14, and the service mesh component 13 in the microservice cluster 15. The traffic collection agent 12 is deployed at the entry point of the microservice cluster 15 and is responsible for intercepting communication data packets directed to the asset node 151 and reporting the interception results to the security management platform 11. Service mesh component 13 runs alongside each asset node 151 in the form of a sidecar proxy, responsible for uniformly intercepting and passing through all traffic entering and leaving the asset node 151, while also supporting end-to-end persistence of custom tracking extension fields; The vulnerability scanning engine 14 receives scanning instructions from the security management platform 11 and performs differentiated scanning on each asset node 151 according to the determined vulnerability scanning priority. The security management platform 11 reads all asset node 151 information and call chain records from the registry center of the microservice cluster 15, thereby completing the construction of business call topology, extraction of standard traffic trajectory, calculation of risk weight and determination of vulnerability scanning priority.

[0024] Based on the aforementioned system architecture, this application provides a method for intelligent prioritization of vulnerability scanning based on asset importance. See also... Figure 2 As shown, the method includes: Step S1: Obtain the asset nodes, vulnerability list, and call chain of the microservice cluster to construct the business call topology, and extract the standard traffic trajectory of the asset nodes.

[0025] The specific implementation process for this step is as follows: First, read all online asset node 151 information from the registration center and configuration management platform of microservice cluster 15. Asset node 151 refers to the service instance that carries specific business functions. This asset node 151 includes independently running service individuals such as order service instance, payment service instance, and inventory service instance. At the same time, a vulnerability list is obtained. The vulnerability list refers to the record file formed by the vulnerability scanning engine 14 after checking the open source component version, configuration items and open ports of each asset node 151 in the previous period. The vulnerability list includes the number of each vulnerability, the node identifier to which it belongs and the corresponding risk rating score. Next, obtain the call chain, which refers to the remote call records between service instances collected by the service mesh component 13. The call chain includes the call initiator identifier, the call receiver identifier, and the timestamp of the call.

[0026] Then, using asset node 151 as the vertex of the graph and the dependency relationship from the initiator to the receiver recorded in the call chain as the directed edge, a directed graph modeling method is used to construct the business call topology. The business call topology is used to reflect the dependency structure between each asset node 151 within the entire microservice cluster 15, and the direction of the edge indicates the flow direction of the business request.

[0027] Finally, the standard traffic trajectory of each asset node 151 is extracted. The standard traffic trajectory refers to the baseline of request behavior of asset node 151 under normal operation without external attacks. The data expression form of the standard traffic trajectory is a multi-dimensional time series profile composed of the trigger sequence as the horizontal axis and the response delay parameter as the vertical axis.

[0028] The specific extraction method is to collect the business request time sequence and response delay parameters triggered between asset nodes 151 in a continuous time period under non-attack conditions, classify and statistically analyze the types of request instructions in the business request time sequence to determine the triggering order, and construct the trigger envelope profile for each type of request instruction within a multi-dimensional time window based on the triggering order and response delay parameters. The multidimensional time window refers to a statistical interval composed of time granularity dimension, sliding window length dimension, and request command type dimension. The multidimensional division is adopted because a single dimension is difficult to reflect the coupling relationship between request type, time distribution, and response speed at the same time.

[0029] The trigger envelope profile refers to the boundary curves drawn according to the type of request instruction. Its formation process is to collect the trigger timing and response delay data points of the same type of request instruction in multiple observation periods, use the sequence constraint to ensure the monotonicity of the horizontal coordinate, use the delay range constraint to determine the upper and lower limits of the vertical coordinate, and finally connect them to form a closed boundary that surrounds all normal data points. The trigger envelope profile is used as the standard flow trajectory of asset node 151.

[0030] In practical engineering applications, suppose that the registry center of a certain microservice cluster 15 reads 5 asset nodes 151, namely node A which carries order business, node B which carries payment business, node C which carries inventory business, node D which carries log business, and node E which carries notification business.

[0031] The call chain records collected by the service mesh component 13 show that node A initiates a call pointing to node B and node D, node B initiates a call pointing to node C, node C initiates a call pointing to node D, and node E initiates a call pointing to node B. Using the five asset nodes 151 as vertices and the above call relationships as directed edges, a business call topology is constructed. To extract the standard traffic trajectory of node B, a time sequence of business requests under non-attack conditions for seven consecutive days is collected. The request commands are divided into three types: query, write, and reconciliation. The order of triggering is used as the horizontal axis and the response latency parameter is used as the vertical axis. Within a multi-dimensional time window, a closed boundary is plotted for the response latency of query commands, falling within [30, 80] milliseconds; for write commands, the closed boundary is plotted for the response latency, falling within [60, 150] milliseconds; and for reconciliation commands, the closed boundary is plotted for the response latency, falling within [200, 400] milliseconds. These three types of closed boundaries together constitute the standard traffic trajectory of node B. The above example is only one implementation method of this application. In actual applications, each parameter can be adjusted according to the specific business scenario.

[0032] This step constructs a business call topology by acquiring asset nodes, vulnerability lists, and call chains, and extracts standard traffic trajectories, providing a structured topological foundation and behavioral baseline for subsequent anomaly identification and risk assessment.

[0033] Step S2: Traverse along the call dependency direction in the business call topology, calculate the vulnerability diffusion rate based on the number of vulnerabilities and the number of downlink call links, generate the initial risk weight of the asset node, and mark the asset node with multiple upstream calls as risk intersection node to locate the core attack path.

[0034] In step S1, a business call topology has been constructed. The dependencies between asset nodes 151 can be seen intuitively from the business call topology. However, determining which asset nodes 151 deserve more priority cannot be based solely on the number of vulnerabilities in the node itself. It is also necessary to consider the possibility of the vulnerability of the asset node 151 spreading downstream and whether the asset node 151 is located at the convergence point of multiple business paths. Once a node at the convergence point is compromised, the attacker can use the node to continue to spread to multiple downstream links, causing a chain of security incidents. Therefore, this step generates an initial risk weight through the vulnerability spread rate and marks the node at the convergence point as a risk intersection node, thereby locating the core attack path at the topology level.

[0035] See Figure 3 As shown, the specific implementation process of this step is as follows: The first step is to read the risk rating scores from the vulnerability list associated with asset node 151 and add up the risk rating scores to obtain the basic vulnerability score. The risk rating scores adopt the values ​​under the general vulnerability scoring system, with a value range of 0 to 10. Regardless of whether the original vulnerability list records them in the form of high, medium, and low levels or in numerical form, they are uniformly mapped to this numerical range before being added to ensure the comparability of the basic vulnerability scores.

[0036] The second step is to count the total number of outgoing connections from asset node 151 to other downstream asset nodes 151 in the business call topology. The total number of outgoing connections is taken as the downlink quantity. Then, the vulnerability spread rate is obtained by multiplying the basic vulnerability score and the downlink quantity. The vulnerability spread rate refers to the potential ability of a vulnerability in asset node 151 to spread to other nodes through its downstream call links. The product of the basic vulnerability score and the downlink quantity means that the node is both likely to be compromised and the breadth of the impact after the compromise.

[0037] The third step is to multiply the preset business carrying importance parameter with the vulnerability spread rate to obtain the initial risk weight. The business carrying importance parameter is a pre-set value describing the position of the business carried by the node in the overall business system. The value is assigned based on the role of the microservice corresponding to asset node 151 in the business process. Service instances located in the core transaction link are assigned higher values, and service instances located in the auxiliary query link are assigned lower values. The specific value range is between 0 and 1.

[0038] The fourth step is to backtrack along the call dependency direction of the business call topology and count the number of independent call chains that directly point to the same asset node 151. When the number of independent call chains is greater than or equal to the preset call path threshold, it is determined that the asset node 151 is handling multi-source business requests and the asset node 151 is marked as a risk intersection node. The risk intersection node refers to the asset node 151 that simultaneously handles requests from multiple independent upstream businesses in the business call topology. The preset call path threshold is an adaptively set judgment threshold based on the overall scale and topology complexity of the microservice cluster 15. In terms of judgment logic, only independent call chains that directly point to the same node are used as the statistical benchmark, and indirect upstream calls are no longer traced back. This is because direct call relationships best reflect the multi-source aggregation responsibilities currently undertaken by the node. If indirect upstream calls are included in the statistics, redundant counting may occur due to the shared upstream entry point.

[0039] The fifth step involves constructing a core attack path, which consists of several paths extending downstream from the risk intersection node, with the risk intersection node as the necessary node. The core attack path is a sub-topology that describes the range of paths that an attacker is most likely to continue penetrating after breaching the risk intersection node.

[0040] In practical engineering applications, for the initial risk weight calculation of node B, it is assumed that the vulnerability list associated with node B contains 3 vulnerabilities with risk rating scores of 7, 5 and 6 respectively. The basic vulnerability score is obtained by adding the risk rating scores of each vulnerability, i.e., 7+5+6=18.

[0041] Node B has a downlink quantity of 1 in the business call topology, and the vulnerability spread rate is 18×1=18; the business bearer importance parameter corresponding to Node B is 0.8, and the initial risk weight of Node B is 0.8×18=14.4.

[0042] Similarly, the initial risk weight of node A is 0.8×12.5×2=20.0, the initial risk weight of node C is 1.0×6.4×1=6.4, the initial risk weight of node D is 1.0×3.2×1=3.2, and the initial risk weight of node E is 1.0×9.0×1=9.0. Assuming the preset call path threshold is 2, and tracing back along the call dependency direction, node B is directly pointed to by both node A and node E. The number of independent call chains is 2, reaching the preset call path threshold. Therefore, node B is marked as a risk intersection node. The sub-topology extending downstream from node B is the core attack path. The above example is only one implementation method of this application.

[0043] This step calculates the vulnerability spread rate and marks risk intersection nodes by traversing along the call dependency direction, thus achieving the initial location of the core attack path at the topology level, and providing a set of key target nodes for subsequent runtime anomaly identification.

[0044] Step S3: Intercept communication data packets pointing to the risk intersection node, draw real-time traffic trajectories, and extract trajectory deviation features from the standard traffic trajectory to map abnormal call intentions targeting the core attack path.

[0045] In step S2, risk intersection nodes located on the core attack path have been identified. These risk intersection nodes are the target locations where attackers are most likely to launch abnormal calls. However, static topology information alone cannot determine whether there is abnormal call behavior. Abnormal calls launched by attackers are often hidden in normal business traffic. Only by comparing the real-time traffic collected during operation with the standard traffic trajectory established in step S1 can the deviation be revealed. Therefore, this step maps the abnormal call intent by intercepting communication data packets, drawing real-time traffic trajectories, and extracting trajectory deviation features.

[0046] See Figure 4 As shown, the process of drawing real-time traffic trajectories is as follows: First, the traffic acquisition agent 12 mirrors and intercepts all inbound communication data packets pointing to the risk intersection node, extracting the payload instruction set and arrival time interval from each communication data packet. The payload instruction set refers to the type identifier of all service request instructions carried in the payload part of the communication data packet, and the arrival time interval refers to the time difference between two adjacent communication data packets arriving at the risk intersection node, in milliseconds.

[0047] Then, the intercepted communication data packets are arranged according to their arrival time. Each request instruction in the payload instruction set is classified according to its type. After classification, each request instruction is mapped to a data point in a two-dimensional coordinate system with the triggering order as the horizontal coordinate and the response delay parameter corresponding to the request instruction as the vertical coordinate. All data points of the same request instruction type are arranged by time and connected sequentially to form the operational flow curve of that request instruction type in the current observation period.

[0048] Finally, the runtime traffic curves of all request command types are summarized and superimposed to obtain the real-time traffic trajectory of the risk intersection node at the current moment. The real-time traffic trajectory refers to the runtime traffic curve drawn based on the actual communication data packets pointing to the risk intersection node at the current moment, which uses the same coordinate dimension as the standard traffic trajectory. The real-time traffic trajectory and the standard traffic trajectory can be directly compared in the same two-dimensional coordinate system.

[0049] See Figure 5 As shown, after drawing the real-time traffic trajectory, the real-time traffic trajectory is projected onto its corresponding multi-dimensional time window and compared with the standard traffic trajectory to calculate the coordinate displacement difference. The specific comparison process is as follows: A two-dimensional coordinate system is established within the multi-dimensional time window, using the trigger sequence as the horizontal coordinate and the response delay parameter as the vertical coordinate. Each data point in the real-time traffic trajectory corresponds to a coordinate value in this two-dimensional coordinate system. The trigger envelope connection of the standard traffic trajectory forms a set of closed boundary line segments in this two-dimensional coordinate system. The trigger envelope connection refers to the set of boundary line segments that constitute the trigger envelope contour mentioned in step S1, and both point to the same object. For each data point in the real-time traffic trajectory that falls outside the trigger envelope connection, the shortest distance between the data point and the nearest trigger envelope connection is calculated using the Euclidean distance formula. This shortest distance is the coordinate displacement difference, and the unit of the coordinate displacement difference is the same as that of the vertical coordinate, which is milliseconds. For data points that fall within the trigger envelope connection, their coordinate displacement difference is recorded as 0, indicating that the data point is within the normal range and does not constitute a deviation.

[0050] After calculating the coordinate displacement difference, the frequency of sudden increases in the coordinate displacement difference within consecutive periods is statistically analyzed. The criterion for a sudden increase is that the increment of the coordinate displacement difference between adjacent periods exceeds twice the historical average. Each increment that meets this criterion within several consecutive periods is counted as a sudden increase. The number of sudden increases per unit time is the sudden increase frequency. The coordinate displacement difference and the sudden increase frequency are used together as trajectory deviation features. The trajectory deviation features refer to the deviation measure of the real-time flow trajectory relative to the standard flow trajectory within a multi-dimensional time window, including the magnitude of the deviation and the frequency of deviation.

[0051] After obtaining the trajectory deviation characteristics, it is necessary to further map the trajectory deviation characteristics to the quantitative level of abnormal call intent, where abnormal call intent refers to the attacker's attempt to probe or intrude into risk intersection nodes by adjusting the request type, changing the request timing, etc. The mapping method involves establishing a preset deviation level mapping table. This deviation level mapping table uses the normalized value of the coordinate displacement difference and the normalized value of the sudden increase frequency as two-dimensional inputs, and the quantized level of the abnormal call intent as the output. The specific content is shown in Table 1.

[0052] Table 1 Deviation Level Mapping Table

[0053] In practical engineering applications, for the real-time traffic trajectory plotting of node B, the traffic acquisition agent 12 intercepts communication data packets pointing to node B and extracts the payload instruction set. It is found that in addition to normal query and write instructions, there are also abnormally dense calls to reconciliation instructions. The arrival time interval has been shortened from the normal average of 400 milliseconds to an average of 80 milliseconds. The real-time traffic trajectory of node B is plotted according to the triggering order and response delay parameters. The real-time traffic trajectory is projected onto a multi-dimensional time window. It is observed that the vertical coordinate value of the data point of the reconciliation instruction is 520 milliseconds, which exceeds the upper limit of 400 milliseconds of the trigger envelope connection line of the reconciliation instruction in the standard traffic trajectory. The coordinate displacement difference is calculated to be |520-400|=120 milliseconds. The normalization process involves dividing the coordinate displacement difference by the historical maximum offset of node B, which is 200 milliseconds. Therefore, the normalized coordinate displacement difference is 120 ÷ 200 = 0.6. Over 10 consecutive observation periods, the coordinate displacement differences for each period were 40, 50, 110, 120, 45, 115, 130, 55, 125, and 120 milliseconds, respectively. The historical average was approximately 91 milliseconds, and twice the historical average was approximately 182 milliseconds. There were four instances of increments exceeding 182 milliseconds between adjacent periods, resulting in four sudden increases and a sudden increase frequency of 4 ÷ 10 = 0.4. Substituting the normalized coordinate displacement difference of 0.6 and the sudden increase frequency of 0.4 into the deviation level mapping table, since 0.6 is greater than the threshold value of 0.6, the mapping result is a high-risk level, indicating that node B is currently facing a high-risk abnormal call intent. The above example is merely one implementation method of this application.

[0054] This step captures real-time traffic trajectories by intercepting communication data packets pointing to risk intersection nodes and extracting trajectory deviation features, thereby enabling runtime awareness of abnormal call intentions on core attack paths and allowing risk assessment to extend from static to dynamic.

[0055] Step S4: Encapsulate the protocol header of the communication data packet injected with the trap tag into a probe block, and allow it to pass downstream of the risk intersection node.

[0056] In step S3, the abnormal call intent targeting the core attack path has been obtained. However, simply identifying the abnormal call itself is not enough to determine the extent to which the abnormal call will spread downstream if it succeeds. Once the attacker breaks through the risk intersection node, its lateral movement path downstream is uncertain. It is necessary to use active tracking methods to sample the actual spread path. Therefore, this step injects the decoy tag into the protocol header to form a probe block and allows it to be passed downstream so that its flow path can be tracked in subsequent steps.

[0057] See Figure 6 As shown, the specific implementation process of this step is as follows: First, the context metadata control area of ​​the intercepted communication data packet is read, while the business logic load area of ​​the communication data packet is avoided. The context metadata control area refers to the field area in the communication protocol used to carry metadata information unrelated to the business load. The metadata carried in this field area includes routing and diagnostic information such as request source identifier, link tracing number, timestamp, and custom extended key-value pairs. In the case of the Hypertext Transfer Protocol, it is located in the extended field area of ​​the request header, and in the case of the Remote Procedure Call framework, it is located in the metadata mapping segment in the frame header. The business logic load area refers to the payload part of the communication data packet that carries the actual business request parameters and response data. This business logic load area includes serialized business object data, request parameter list, and return value data, etc., which are directly related to business processing. When writing the decoy tag, this business logic load area is strictly avoided to ensure that normal business communication is not affected.

[0058] Then, a custom tracing extension field is added to the context metadata control area, and the trap label is written into the custom tracing extension field. The trap label refers to the characteristic data fragment generated by this method for tracing the abnormal request flow path within the microservice cluster 15. The trap label includes a globally unique number used to identify this injection event and a hash digest used to verify integrity. The unique generation rule for the trap tag can be set according to requirements. For example, this application adopts a joint hashing method of timestamp and node identifier. The specific hashing algorithm uses the message digest algorithm to perform hashing operation on the concatenated string of timestamp and node identifier, and takes the first 16 bits of the hash result as the unique number of the trap tag.

[0059] Finally, the control information of the communication data packets written to the decoy tag is updated through verification and recalculation to form a probe block. Verification and recalculation refers to recalculating the verification field in the control information of the modified communication data packets according to the verification algorithm specified in the original communication protocol. Specifically, the recalculation process involves accumulating all bytes of the modified communication data packets group by group according to the grouping method specified by the verification algorithm, and taking the inverse code of the accumulation result as the new value of the verification field. This method ensures that the receiver can obtain consistent results when verifying the received communication data packets according to the same algorithm, thus not rejecting the data packets. The verification and recalculation mechanism can be set according to requirements. For example, this application adopts a transparent proxy correction method, which completes the recalculation at the data packet exit position before releasing it, thus keeping normal business communication unnoticed. The formed probe block is released downstream of the risk intersection node by the traffic collection proxy 12.

[0060] In practical engineering applications, for the probe block encapsulation of node B, the traffic acquisition agent 12 reads the intercepted communication data packets, identifies that the communication data packets use the Hypertext Transfer Protocol, and locates the extended field area of ​​the request header as the context metadata control area; a custom trace extension field named "Trace Extension" is added to the context metadata control area, and a 16-bit tag string in the form of a3f8b9c2d1e04567 is obtained by concatenating the timestamp 1707123456 with the node identifier B and performing a message digest algorithm hash operation. This tag is used as a decoy tag. The capture tag has a byte length of 16 bytes. After writing the custom tracking extension field, the total length of the communication data packet increases from the original 512 bytes to 528 bytes. The original value of the check field in the control information of the communication data packet is 0x4A2F. The modified 528-byte communication data packet is accumulated in groups of 16 bits and then the inverse code is taken to obtain the new check field value of 0x5B3C. The new check field value is written back to the control information. After forming a probe block, the traffic acquisition agent 12 releases the data to the downstream node C of node B. The above example is only one implementation method of this application.

[0061] This step lays an observable foundation for subsequent tracking of the lateral spread of threats by injecting the decoy tag into the protocol header, encapsulating it as a probe block, and releasing it downstream to the risk convergence node.

[0062] Step S5: Track the flow path of the probe block to extract the threat spread radius in order to quantify the potential lateral movement range caused by the abnormal call intent.

[0063] In step S4, the probe block has been allowed to pass downstream of the risk intersection node. However, the probe block itself is only an observable carrier. Only by tracking the actual flow path of the probe block within the microservice cluster 15 and extracting quantitative indicators can the potential lateral movement range caused by the abnormal call intent be transformed into a calculable value. Therefore, this step extracts the threat diffusion radius by tracking the flow path, so that the subsequent calculation of corrected risk weights has complete input.

[0064] The specific implementation process for this step is as follows: First, the sidecar proxy of the service mesh component 13 captures the forwarded data streams carrying custom tracing extension fields inside the microservice cluster 15. The service mesh component 13 uniformly intercepts all inbound and outbound traffic and retains the custom extension fields, thereby ensuring that the tracing labels of the probe block are not stripped when it is called across services.

[0065] Then, the total number of hop nodes traversed by the forwarded data stream and the initial risk weight of each asset node 151 are recorded. The hop count in the total number of hop nodes is defined as each independent service instance traversed by the forwarded data stream. Only the process of receiving and forwarding data at the application layer is used as the statistical basis; the transit of underlying network devices is not included in the hop count. The initial risk weight value can be set according to the actual situation.

[0066] Finally, the total number of hop nodes is multiplied by the sum of the initial risk weights of each asset node 151 along the path, and the product is used as the threat diffusion radius. The threat diffusion radius is a quantitative indicator of lateral movement jointly characterized by the number of asset nodes 151 traversed by the probe block within the microservice cluster 15 and the initial risk weight of each asset node 151. The total number of hop nodes characterizes the distance dimension of lateral movement, and the sum of the initial risk weights characterizes the overall importance dimension of the nodes traversed. Multiplying the two can simultaneously reflect the breadth and depth of lateral movement.

[0067] In practical engineering applications, for the flow tracking of downstream probe blocks of node B, the sidecar agent of service mesh component 13 captures the forwarded data stream carrying a custom tracking extension field and records that the forwarded data stream is sent out by node B, first reaches node C and then continues to be forwarded to reach node D, with a total of 2 skipped nodes.

[0068] Assuming the initial risk weight of path node C is 6.4 and the initial risk weight of path node D is 3.2, the cumulative initial risk weight is 6.4 + 3.2 = 9.6. Multiplying the total number of hop nodes 2 by the cumulative initial risk weight of 9.6, we get the threat spread radius as 2 × 9.6 = 19.2. The above example is only one implementation of this application.

[0069] This step extracts the threat diffusion radius by tracing the flow path of the probe block, enabling the calculable quantification of the lateral movement range and providing a key input from the downstream diffusion dimension for correcting risk weights.

[0070] Step S6: Combining the abnormal call intent and the lateral movement range, perform a corrected weighted calculation on the initial risk weights of the risk intersection nodes on the core attack path to obtain the corrected risk weights. The non-intersection nodes retain the initial risk weights, and determine the vulnerability scanning priority of all asset nodes according to the order of weight values ​​from high to low.

[0071] In steps S3 and S5, the trajectory deviation feature reflecting the abnormal call intent and the threat diffusion radius reflecting the lateral movement range have been obtained respectively. These two types of information come from the upstream detection dimension and the downstream diffusion dimension, respectively. Only by integrating the two with the initial risk weight obtained in step S2 can we obtain the corrected risk weight that considers both the static topological importance and the actual threat distribution during operation. Therefore, this step integrates the three aspects of information through corrected weighted calculation.

[0072] See Figure 7 As shown, the specific implementation process of this step is as follows: The first step is to convert the trajectory deviation features into deviation penalty factors. The formula for calculating the deviation penalty factors is (1):

[0073] In the calculation formula (1): The deviation penalty factor is dimensionless. This is a normalized value of the coordinate displacement difference, dimensionless, and is calculated by dividing the coordinate displacement difference by the historical maximum offset value of the risk intersection node. This is a normalized value for the burst frequency, dimensionless, and is calculated by dividing the number of bursts by the total number of observation periods. is the weighting coefficient for the coordinate displacement difference, dimensionless; The weighting coefficients for the sudden increase in frequency are dimensionless. and The sum is 1; the constant 1 in the formula serves as a benchmark value, ensuring that the deviation penalty factor is 1 when there is no deviation, thus preventing the reduction of the initial risk weight.

[0074] The second step is to convert the threat diffusion radius into a risk amplification index. The risk amplification index is calculated using a piecewise linear mapping function, and its calculation formula (2) is as follows:

[0075] In the calculation formula (2): k is the risk amplification index, which is dimensionless; D is the threat diffusion radius, which is the number of jumps multiplied by the risk score. It represents the lower limit of the index within its segment, and is dimensionless. It represents the upper limit of the exponent within its segment, and is dimensionless. This is the lower limit of the threat diffusion radius within the corresponding segment; This represents the upper limit of the threat spread radius within its respective segment; the segmentation rule is that a threat spread radius between 0 and 10 indicates mild spread. Take 1.0, Take 1.1; when the threat diffusion radius is between 10 and 30, it is considered moderate diffusion. Take 1.1, A value of 1.5 is used; a threat diffusion radius greater than 30 is considered severe diffusion. Take 1.5, The value is set to 2.0. To prevent the weight from growing too fast, an upper limit is set for the risk amplification index. When the mapping result exceeds the upper limit, it is truncated. The upper limit is between 2 and 3.

[0076] The third step involves using the initial risk weight of the risk convergence node as the base, performing an exponential calculation with the risk amplification index as the power, and multiplying the result of the exponential calculation with the deviation penalty factor to obtain the corrected risk weight of the risk convergence node. Non-convergence nodes do not participate in the corrected weighting calculation and directly use their initial risk weight as the final weight value for sorting.

[0077] The formula (3) for calculating the adjusted risk weight is as follows:

[0078] The calculation formula (3) is as follows: To adjust the risk weights, dimensionless, The deviation penalty factor is dimensionless. The initial risk weights for the risk intersection nodes are dimensionless. This is a risk amplification index, dimensionless.

[0079] The reason for using exponential calculation with the initial risk weight as the base and the risk amplification index as the power is that exponential calculation can produce a non-linear amplification effect on the base when the risk amplification index increases. Compared with simple linear multiplication, exponential calculation can more sensitively distinguish nodes with small differences in diffusion range but large differences in threat level. When the initial risk weights of two risk intersection nodes are close, the risk amplification index corresponding to the node with a larger threat diffusion radius is higher. The difference in corrected risk weights obtained after exponential calculation will be reasonably amplified, so that the priority ranking can better reflect the actual threat distribution.

[0080] The fourth step is to sort all asset nodes 151 from highest to lowest weight values. The sorting result is the vulnerability scanning priority.

[0081] In practical engineering applications, for node B, the result obtained from step S3 is... =0.6、 =0.4, weighting coefficient =0.5、 =0.5, substituting into the calculation formula (1) yields From step S5, the threat diffusion radius D = 19.2, which is in the medium diffusion segment. Substituting this into the calculation formula (2), we get... Take an approximate value Substituting into the corrected calculation formula (3), we get All asset nodes 151 are sorted by weight from high to low as node B, node A, node E, node C, and node D. The above example is only one implementation method of this application.

[0082] To more intuitively demonstrate the key parameters and final sorting results of each node, the key parameters and final sorting results of each node in the above example are shown in Table 2 below.

[0083] Table 2. Examples of key parameters for each node and the final sorting results.

[0084] As can be seen from Table 2 above, although the initial risk weight of node A is higher than that of node B, node B is a risk intersection node and currently has abnormal calling intentions and lateral spread threats. After correction, the final weight of node B surpasses that of node A and ranks first.

[0085] This step involves recalculating the initial risk weights by combining the intent of abnormal calls with the lateral movement range. This achieves a deep integration of static topology information and runtime dynamic information, enabling vulnerability scanning priorities to more accurately reflect the true importance of asset nodes under the current attack situation.

[0086] After determining the vulnerability scanning priority in step S6, in order to translate the priority into specific scanning actions, it is necessary to further allocate scanning resources and issue scanning instructions based on the sorting results.

[0087] See Figure 8 As shown, the specific process of resource allocation and command issuance is as follows: First, according to the vulnerability scanning priority from high to low, scanning concurrent thread resources are allocated to all asset nodes 151 in turn. The asset nodes 151 with higher priority are given more concurrent threads to ensure that high-priority nodes can be scanned as quickly as possible.

[0088] Then, the first asset node ranked within the priority set ratio is extracted, and a penetration scan command containing a deep probing script is issued to the extracted first asset node. The principle for determining the priority set ratio is to take into account the total number of asset nodes 151 and the vulnerability scanning resource capacity, and select the top 20% to 30% of nodes in the medium-sized microservice cluster 15.

[0089] The deep probing script included in the penetrating scan command refers to a verification script written for the specific exploitation path of known vulnerabilities in a component. The execution process involves a thorough probing of the target node's ports, component versions, configuration items, and potential vulnerability exploitation surfaces.

[0090] Finally, extract the second asset node that is outside the priority setting ratio, and issue a comparative scan command including port detection to the extracted second asset node. The comparative scan command verifies whether the open ports and component fingerprints of the target node are within the scope of the known vulnerability database in a fast comparison method. The scan time is short and it is suitable for nodes with relatively low risk levels.

[0091] In practical engineering applications, it is assumed that the priority is set to select the top 40% of nodes, that is, nodes B and A are classified as the first asset nodes. The vulnerability scanning engine 14 issues penetration scanning instructions for nodes B and A, and comparison scanning instructions for nodes E, C, and D. At the same time, scanning concurrent threads are allocated according to priority order, with node B obtaining 5 concurrent threads, node A obtaining 4 concurrent threads, and nodes E, C, and D each obtaining 2 concurrent threads. The above example is only one implementation method of this application.

[0092] In one specific implementation, when the microservice cluster 15 is small in size and does not contain obvious risk intersection nodes, this method can degenerate into sorting based solely on the initial risk weight. The correction process from step S3 to step S6 can be omitted, and the initial risk weight obtained in step S2 can be directly used as the basis for vulnerability scanning priority, thereby reducing implementation overhead while retaining the main functions.

[0093] In another specific implementation, when the microservice cluster 15 involves mixed calls of multiple communication protocols, the writing position of the custom tracking extension field can be configured for different protocols in step S4. For the Hypertext Transfer Protocol, it is written in the request header, and for the Remote Procedure Call Framework, it is written in the metadata description, so as to ensure that the trapping tag can still maintain traceability when it propagates across protocols.

[0094] This application combines information from the entire chain of microservice call topology, runtime traffic anomalies, and threat lateral propagation to enable asset nodes located on core attack paths to be identified first and assigned higher scanning intensity. This can improve the utilization efficiency of vulnerability scanning resources, enhance the real-time awareness of core attack paths, and reduce the risk of critical business operations being subjected to lateral penetration.

[0095] This application also provides an intelligent priority ranking system for vulnerability scanning based on asset importance, the system comprising: The acquisition module is used to acquire the asset nodes, vulnerability list, and call chain of the microservice cluster to construct the business call topology, and to extract the standard traffic trajectory of the asset nodes.

[0096] The calculation module is used to traverse along the call dependency direction in the business call topology, calculate the vulnerability diffusion rate based on the number of vulnerabilities and the number of downlink call links, generate the initial risk weight of the asset node, and mark the asset node with multiple upstream calls as risk intersection node to locate the core attack path.

[0097] The extraction module is used to intercept communication data packets pointing to the risk intersection node, draw real-time traffic trajectories, and extract trajectory deviation features from the standard traffic trajectory to map abnormal call intentions targeting the core attack path.

[0098] An injection module is used to encapsulate the protocol header of the communication data packet injected with the decoy tag into a probe block and allow it to pass downstream of the risk intersection node.

[0099] The quantization module is used to track the flow path of the probe block to extract the threat diffusion radius, so as to quantify the potential lateral movement range caused by the abnormal invocation intent.

[0100] The correction module is used to combine the abnormal call intent and the lateral movement range to perform a corrected weighted calculation on the initial risk weight of the risk intersection nodes on the core attack path, and calculate the corrected risk weight. The non-intersection nodes retain the initial risk weight, and the vulnerability scanning priority of all asset nodes is determined according to the order of the weight values ​​from high to low.

[0101] The vulnerability scanning intelligent priority ranking system based on asset importance in this application is used to implement the aforementioned vulnerability scanning intelligent priority ranking method based on asset importance. Therefore, the specific implementation of the vulnerability scanning intelligent priority ranking system based on asset importance can be found in the embodiment section of the vulnerability scanning intelligent priority ranking method based on asset importance mentioned above. The specific implementation can be referred to the description of the corresponding embodiment, and will not be repeated here.

[0102] This application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described asset-importance-based vulnerability scanning intelligent priority ranking methods.

[0103] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the above-described intelligent priority ranking methods for vulnerability scanning based on asset importance.

[0104] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory, random access memory, portable hard drives, magnetic disks, or optical disks.

[0105] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the intelligent priority ranking method for vulnerability scanning based on asset importance.

[0106] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0107] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0108] The above provides a detailed description of the intelligent priority ranking method and system for vulnerability scanning based on asset importance provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. An asset importance based intelligent prioritization of vulnerability scanning method, characterized in that, include: Obtain the asset nodes, vulnerability list, and call chain of the microservice cluster to construct the business call topology, and extract the standard traffic trajectory of the asset nodes; Traverse along the call dependency direction in the business call topology, calculate the vulnerability spread rate based on the number of vulnerabilities and the number of downlink call links, generate the initial risk weight of the asset node, and mark the asset node with multiple upstream calls as risk intersection node to locate the core attack path; Intercepting communication data packets directed to the risk intersection node, drawing real-time traffic trajectories, and extracting trajectory deviation features from the standard traffic trajectory to map abnormal call intentions targeting the core attack path; The decoy tag is injected into the protocol header of the communication data packet and encapsulated as a probe block, and then allowed to pass downstream of the risk intersection node; The threat spread radius is extracted by tracing the flow path of the probe block in order to quantify the potential lateral movement range caused by the abnormal invocation intent; Combining the abnormal call intent and the lateral movement range, the initial risk weights of the risk intersection nodes on the core attack path are modified and weighted to calculate the modified risk weights. The non-intersection nodes retain the initial risk weights, and the vulnerability scanning priority of all asset nodes is determined according to the order of weight values ​​from high to low.

2. The method according to claim 1, characterized in that, The extraction of the standard traffic trajectory of the asset node includes: Collect the timing sequence of business requests triggered between the asset nodes and the response latency parameters during a continuous time period when the asset nodes are in a non-attack state; The request instruction types in the business request time sequence are classified and statistically analyzed to determine the triggering order of the request instruction types. Based on the triggering order and the response delay parameter, a trigger envelope profile for each request instruction type is constructed within a multi-dimensional time window. The trigger envelope profile is used as the standard traffic trajectory of the asset node.

3. The method according to claim 1, characterized in that, The calculation of vulnerability spread rate based on vulnerability quantity and downlink quantity, and the generation of initial risk weights for the asset nodes, includes: Read the risk rating scores from the vulnerability list associated with the asset node, and add up the risk rating scores to obtain the basic vulnerability score; The total number of outgoing connections from the asset node to other downstream asset nodes in the business call topology is counted, and the total number of outgoing connections is used as the downlink quantity. The vulnerability spread rate is obtained by multiplying the basic vulnerability score with the downlink quantity. The initial risk weight of the asset node is obtained by multiplying the preset business carrying importance parameter with the vulnerability diffusion rate.

4. The method according to claim 1, characterized in that, The step of marking asset nodes with multiple upstream calls as risk convergence nodes includes: Backtrack in reverse along the call dependency direction of the business call topology to count the number of independent call chains that directly point to the same asset node; When the number of independent call chains is greater than or equal to a preset call path threshold, it is determined that the asset node accepts multi-source business requests, and the asset node that is determined to accept multi-source business requests is marked as a risk convergence node.

5. The method according to claim 1, characterized in that, The interception of communication data packets pointing to the risk convergence node, the plotting of real-time traffic trajectories, and the extraction of trajectory deviation features from the standard traffic trajectory include: The intercepted communication data packets are analyzed to obtain the payload instruction set and arrival time interval, and a real-time traffic trajectory is drawn for the risk intersection node based on the payload instruction set and arrival time interval. The real-time traffic trajectory is projected onto its corresponding multi-dimensional time window, and the coordinate displacement difference between the real-time traffic trajectory and the trigger envelope contour of the standard traffic trajectory is obtained by comparison. The frequency of sudden increases in the coordinate displacement difference within a continuous period is statistically analyzed, and the frequency of sudden increases and the coordinate displacement difference are used as trajectory deviation features.

6. The method according to claim 1, characterized in that, The step of encapsulating the protocol header of the communication data packet containing the decoy tag into a probe block includes: Read the context metadata control area of ​​the communication data packet to bypass the business logic load area of ​​the communication data packet; Add a custom tracking extension field within the context metadata control area, and write the trapping tag into the custom tracking extension field; The control information of the communication data packets written to the decoy tag is updated by verification and recalculation to form a probe block.

7. The method according to claim 1, characterized in that, The step of tracing the flow path of the probe block to extract the threat spread radius includes: Capture the forwarded data stream carrying custom tracing extension fields within the microservice cluster; Record the total number of hop nodes of the asset nodes through which the forwarded data stream passes, and the initial risk weight of each asset node along the path; The total number of jump nodes is multiplied by the sum of the initial risk weights of each of the asset nodes along the path, and the product is used as the threat diffusion radius.

8. The method according to claim 1, characterized in that, The method involves combining the abnormal call intent with the lateral movement range to perform a corrected weighted calculation on the initial risk weights of the risk intersection nodes on the core attack path, resulting in a corrected risk weight, including: The trajectory deviation features mapped by the abnormal call intent are transformed into deviation penalty factors; The threat spread radius quantified by the lateral movement range is converted into a risk amplification index; Using the initial risk weight of the risk intersection node as the base, and the risk amplification index as the power, an exponential operation is performed. The result of the exponential operation is then multiplied by the deviation penalty factor to obtain the corrected risk weight of the risk intersection node.

9. The method according to claim 1, characterized in that, After determining the vulnerability scanning priority of all asset nodes according to their weight values ​​from high to low, the method further includes: According to the sorting result of vulnerability scanning priority from high to low, scan concurrent thread resources are allocated to all the asset nodes in sequence; Extract the first asset node that ranks within the priority set ratio, and issue a penetration scan command containing a depth detection script to the extracted first asset node; Extract the second asset node that is outside the priority setting ratio, and issue a comparison scan command including port detection to the extracted second asset node.

10. A vulnerability scanning intelligent priority ranking system based on asset importance, characterized in that, include: The acquisition module is used to acquire the asset nodes, vulnerability list, and call chain of the microservice cluster to construct the business call topology, and to extract the standard traffic trajectory of the asset nodes; The calculation module is used to traverse along the call dependency direction in the business call topology, calculate the vulnerability spread rate based on the number of vulnerabilities and the number of downlink call links, generate the initial risk weight of the asset node, and mark the asset node with multiple upstream calls as risk intersection node in order to locate the core attack path. The extraction module is used to intercept communication data packets pointing to the risk intersection node, draw real-time traffic trajectories, and extract trajectory deviation features from the standard traffic trajectory to map abnormal call intentions targeting the core attack path. An injection module is used to encapsulate the protocol header of the communication data packet injected with the decoy tag into a probe block and allow it to pass downstream of the risk intersection node; The quantization module is used to track the flow path of the probe block to extract the threat diffusion radius, so as to quantify the potential lateral movement range caused by the abnormal calling intent; The correction module is used to combine the abnormal call intent and the lateral movement range to perform a corrected weighted calculation on the initial risk weight of the risk intersection nodes on the core attack path, and calculate the corrected risk weight. The non-intersection nodes retain the initial risk weight, and the vulnerability scanning priority of all asset nodes is determined according to the order of the weight values ​​from high to low.

Images