Collection analysis and utilization linkage method for full life cycle of vulnerability intelligence

Abstract

The invention discloses a collection, analysis and utilization linkage method for the full life cycle of vulnerability intelligence, which comprises the following steps: respectively acquiring original vulnerability intelligence of a plurality of heterogeneous data sources, and carrying out standardization processing on the original vulnerability intelligence to obtain vulnerability description information; constructing an asset knowledge graph, wherein the asset knowledge graph is used for representing IT asset objects in the enterprise and dependency and deployment relationships among the IT asset objects; performing graph traversal query on the vulnerability description information based on an asset knowledge graph, and identifying an affected asset list affected by vulnerabilities; and according to a preset response strategy, generating a safety response instruction from the affected asset list and sending the safety response instruction to the safety protection system. According to the method, the asset knowledge graph is constructed and the multi-source vulnerability information is subjected to standardization and mapping correlation analysis, so that the accurate and rapid identification of the affected assets of the power system and the automatic response strategy generation are realized, and the efficiency and the accuracy of the vulnerability management of the key information infrastructure of the power grid are effectively improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security, in particular to a collection analysis and utilization linkage method for the whole life cycle of vulnerability intelligence. BACKGROUND

[0002] In recent years, with the continuous deepening of the intelligent, digital transformation and upgrading of the power industry, smart grid, power distribution automation, new energy monitoring and power Internet of Things and other new business systems have been widely used. This trend not only improves the efficiency of power grid operation and the level of user service, but also greatly expands the attack surface of the system. A large number of intelligent terminals, industrial control devices, servers and software platforms from different manufacturers are deployed in the power production control area and the management information area. These devices and systems have become the focus of network attacks due to their basic, real-time and continuous requirements. Once the vulnerabilities contained are exploited, it may directly threaten the safe and stable operation of the power grid, and even cause a chain of social public safety incidents.

[0003] The vulnerability management challenges faced by the power industry are particularly special. The sources of vulnerability intelligence are diverse and have obvious heterogeneous characteristics, including special security bulletins and patch information published by the National Energy Administration, internal security departments of power grid companies, and device suppliers, as well as vulnerability abstracts related to industrial control and power in national vulnerability sharing platforms (such as CNVD and CNNVD), and targeted threat intelligence published by industry security organizations. These intelligence formats are different, with great differences in description specifications, and a large number of version identifiers of power-specific protocols, embedded systems and old industrial software. Traditional intelligence processing methods relying on general IT security tools cannot effectively parse and adapt, resulting in incomplete or low-efficiency extraction of key vulnerability information.

[0004] The more core difficulty lies in the complex relationship between internal assets in the power system, which has strict network security zoning (such as the production control area and the management information area) and logical isolation requirements. The impact range assessment of a vulnerability not only needs to identify servers directly installed with a component, but also needs to trace its propagation path in the upper power application business (such as energy management system EMS, distribution management system DMS), lower embedded devices (such as protection and control devices, smart meters), and cross-zone data interaction links. Existing conventional asset management systems or scanning tools cannot dynamically and accurately depict the dependence and deployment relationship of this "cloud, management, edge, and end" multi-layer coupling, resulting in deviations in the impact analysis results, either missing key risk points or expanding the shutdown maintenance range, causing unnecessary disturbance to the power grid operation plan. SUMMARY

[0005] The embodiment of the application aims to provide a vulnerability information full life cycle collection analysis and utilization linkage method, by constructing an asset knowledge graph and performing standardized and graph-based correlation analysis on multi-source vulnerability information, accurate and rapid identification of affected assets of a power system and automatic response strategy generation are realized, and the efficiency and accuracy of vulnerability management of power grid critical information infrastructure are effectively improved.

[0006] To solve the above technical problems, the first aspect of the embodiment of the application provides a vulnerability information full life cycle collection analysis and utilization linkage method, comprising the following steps:

[0007] Raw vulnerability information of a plurality of heterogeneous data sources is acquired respectively, and the raw vulnerability information is standardized to obtain vulnerability description information;

[0008] An asset knowledge graph is constructed, and the asset knowledge graph is used to represent IT asset objects in an enterprise and dependency and deployment relationships between the IT asset objects;

[0009] Based on the asset knowledge graph, graph traversal query is performed on the vulnerability description information to identify an affected asset list affected by the vulnerability;

[0010] According to a preset response strategy, a security response instruction is generated from the affected asset list and sent to a security protection system.

[0011] Further, the graph traversal query based on the asset knowledge graph on the vulnerability description information to identify the affected asset list affected by the vulnerability comprises:

[0012] The vulnerability description information is parsed, and a software component and a version range related to the vulnerability are extracted as vulnerability influence range parameters;

[0013] The vulnerability influence range parameters are used as a starting query condition, and multi-hop traversal query is performed in the asset knowledge graph, the multi-hop traversal query is transmitted along edges representing dependency and deployment relationships in the asset knowledge graph, and IT asset objects directly installed or indirectly dependent on the software component are acquired;

[0014] According to the version information of the IT asset objects and the version range, matching verification is performed, and asset nodes with versions falling within the affected range are screened out as a preliminary affected asset set;

[0015] In combination with business attribute information pre-stored in the asset knowledge graph, a business system, a management person in charge and a security criticality level of each asset node in the preliminary affected asset set are dynamically associated, and an affected asset list containing business context information is generated.

[0016] Further, the multi-hop traversal query in the asset knowledge graph starting from the vulnerability impact range parameter includes:

[0017] The software component in the vulnerability impact range parameter is taken as a query seed node for positioning in the asset knowledge graph, and the query seed node is a starting point for the traversal query;

[0018] Starting from the query seed node, reverse traversal is performed along the dependency edge representing the dependency relationship between software components, and the reverse traversal is to obtain all upstream application nodes directly dependent on the software component in the reverse direction of the dependency relationship;

[0019] Starting from all discovered nodes including the upstream application nodes, traversal is performed along the deployment edge representing the deployment relationship to determine the physical host or cloud server node carrying the software component, and the IT asset object set is obtained.

[0020] Further, the matching verification according to the version information of the IT asset object and the version range includes screening out the asset nodes whose versions fall within the affected range as a preliminary affected asset set, including:

[0021] The asset version information corresponding to each asset node in the IT asset object set is extracted, and the asset version information includes a software version number, a build timestamp and / or a version identifier;

[0022] The software version number is standardized and parsed, and is converted into a uniform format conforming to the semantic version specification;

[0023] Based on the semantic version comparison rule, the standardized software version number is matched with the version range in the vulnerability impact range parameter through a version matching mechanism to determine whether it falls within the start and end version interval of the vulnerability impact;

[0024] For the asset nodes that cannot obtain a valid software version number or the version number does not conform to the semantic version specification, an auxiliary matching mechanism is used for verification, and the auxiliary matching mechanism determines whether the build timestamp is within a specific time period after the vulnerability disclosure time or determines whether the file hash value matches the file hash value of the known affected version;

[0025] The asset nodes confirmed through the version matching mechanism and the asset nodes confirmed through the auxiliary matching mechanism are merged, and the preliminary affected asset set is obtained after deduplication.

[0026] Further, the determination of whether the file hash value matches the file hash value of the known affected version includes:

[0027] Obtain the file hash values ​​of known affected versions from a pre-set trusted security intelligence source;

[0028] The file hash values ​​are subjected to multi-source cross-validation and cleaning and deduplication to construct a dynamically updated polluted file hash library, and each record is appended with a source credibility weight and a recent update timestamp;

[0029] Obtain the current file hash value of the corresponding software node in the IT asset object set;

[0030] The current file hash value is compared with the records in the polluted file hash database, and a verification result of whether a match is obtained based on the matching result and the corresponding record's credibility weight.

[0031] Furthermore, after generating the list of affected assets containing business context information, the process also includes:

[0032] After generating security response instructions based on the affected asset list, extract the vulnerability identifier corresponding to the current vulnerability intelligence, the common feature patterns of assets in the affected asset list, and the type of security response instructions used to generate historical analysis knowledge entries.

[0033] The historical analysis knowledge entries are stored in the historical analysis knowledge base, which stores the analysis and response data of all handled vulnerabilities.

[0034] The newly received vulnerability intelligence is analyzed to obtain its vulnerability impact range parameter. It is then compared with the vulnerability characteristics and asset impact patterns of all historical analysis knowledge entries in the historical analysis knowledge base to calculate the comprehensive similarity score.

[0035] If the combined similarity score between the vulnerability impact range parameter and a historical analysis knowledge entry exceeds a preset similarity threshold, then the security response instruction corresponding to the historical analysis knowledge entry is invoked, and the threat level and handling priority of the newly received vulnerability intelligence are increased.

[0036] Furthermore, the step of generating a security response instruction from the list of affected assets based on a preset response strategy includes:

[0037] A multi-dimensional decision vector is created based on the business criticality level, vulnerability threat level, and real-time network traffic situation information of each asset node in the affected asset list.

[0038] The multidimensional decision vector is processed based on the response decision model to obtain a quantitative response urgency score for each asset node.

[0039] Based on the quantitative response urgency score, response actions matching each level are obtained from the response action library, resulting in corresponding safety response instructions.

[0040] Furthermore, the processing of the multidimensional decision vector based on the response decision model includes:

[0041] A set of historical vulnerability handling records is obtained. For each historical handling record in the set, the historical multidimensional decision vector in the historical handling record is extracted as a basic feature. The topological clustering degree and business dependency density information of the assets affected by the vulnerability are extracted from the asset knowledge graph related to the historical handling record as enhanced features. The basic features and the enhanced features are fused to form the input features of the corresponding training samples of the historical handling record, and the enhanced historical multidimensional decision vector is obtained.

[0042] Based on the repair time, impact index on business service availability, and probability value of successfully blocking the attack of the corresponding response action in the historical handling records, the comprehensive effect score of the response action is calculated and used as the training target of the training sample.

[0043] Using the enhanced historical multidimensional decision vectors of all the training samples as input features and their corresponding comprehensive performance scores as training targets, the model is trained using machine learning algorithms to obtain the response decision model.

[0044] Accordingly, a second aspect of the present invention provides an electronic device, including: at least one processor; and a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processor to perform the above-described method for the collection, analysis and utilization of vulnerability intelligence throughout its entire lifecycle.

[0045] Accordingly, a third aspect of the present invention provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the above-described method for the collection, analysis, and utilization of vulnerability intelligence throughout its entire lifecycle.

[0046] The above-described technical solutions of the embodiments of the present invention have the following beneficial technical effects:

[0047] 1. By constructing a knowledge graph that integrates the complex dependencies and deployment relationships of power assets, and by performing intelligent multi-hop traversal queries and multi-dimensional version verification (including file hash verification) based on vulnerability intelligence, the drawbacks of traditional manual methods, such as low efficiency and easy errors, are overcome. It can automatically, quickly and accurately locate the specific power equipment, business systems and their related links affected by vulnerabilities, greatly improving the comprehensiveness and accuracy of risk identification and providing a reliable basis for subsequent response.

[0048] 2. By constructing a decision-making model that integrates multiple dimensions such as business criticality level, vulnerability threat, and real-time situation, and combining it with a historical experience knowledge base for similarity matching and optimization, it can output differentiated and quantitative response strategies for power assets of different importance and in different scenarios, ensuring a high degree of adaptability and synergy between security measures and business continuity requirements, and achieving the optimal balance between security benefits and operational benefits.

[0049] 3. The complete process, results, and contextual characteristics of each vulnerability handling are accumulated into historical analysis knowledge entries, and a rapid reuse mechanism based on similarity calculation is constructed. It can use the accumulated experience and knowledge to quickly assess and recommend responses to new vulnerabilities, which not only significantly accelerates the response speed to repeated or similar threats, but also improves the maturity and automation level of the security operation system as a whole, and realizes continuous self-optimization of system processing efficiency. Attached Figure Description

[0050] Figure 1 This is a flowchart of a method for the coordinated collection, analysis, and utilization of vulnerability intelligence throughout its entire lifecycle, provided by an embodiment of the present invention. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments and the accompanying drawings. It should be understood that these descriptions are merely exemplary and not intended to limit the scope of the invention. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.

[0052] Please refer to Figure 1 The first aspect of this invention provides a method for the coordinated collection, analysis, and utilization of vulnerability intelligence throughout its entire lifecycle, comprising the following steps:

[0053] Step S100: Obtain raw vulnerability information from multiple heterogeneous data sources, standardize the raw vulnerability information, and obtain vulnerability description information.

[0054] Raw vulnerability intelligence is continuously collected from multiple pre-configured heterogeneous data sources using integrated interfaces or web crawling techniques. These data sources include, but are not limited to, national and industry vulnerability databases (such as CNNVD and CNVD), software vendor security bulletins, open-source threat intelligence, and security alerts issued by industry security organizations. The collected unstructured or semi-structured raw data is processed by a parsing engine to extract key fields and normalize them, forming structured vulnerability description information containing standardized vulnerability identifiers (such as CVE IDs), affected software components, version ranges, vulnerability types, and severity levels. This provides a consistent and reliable data foundation for subsequent analysis.

[0055] Step S200: Construct an asset knowledge graph, which is used to represent IT asset objects within the enterprise and the dependencies and deployment relationships between IT asset objects.

[0056] By combining automated discovery tools with manual registration, static attribute and dynamic relationship data of various IT asset objects in the enterprise network environment are collected. Static attributes include asset type, IP address, operating system, installed software and version number, while dynamic relationships include dependencies between software components, service call chains, and physical deployment relationships. An asset knowledge graph is constructed using graph database technology. Nodes in the graph represent specific asset objects (such as servers, network devices, embedded devices, and application instances), while edges represent various relationships between assets (such as deployed on, dependent on, and connected to), thus forming a comprehensive dynamic topology graph depicting enterprise assets and their complex relationships.

[0057] Step S300: Based on the asset knowledge graph, perform graph traversal query on the vulnerability description information to identify the list of affected assets affected by the vulnerability.

[0058] The system receives the standardized vulnerability description information generated in step S100 and parses out the specified affected software components and their version ranges as key query parameters. Using these parameters as seeds, it performs multi-hop traversal queries on the asset knowledge graph constructed in step S200, tracing back all directly and indirectly related asset nodes along dependency edges and deployment edges. For the traversed set of asset nodes, it further performs precise matching and verification between their version information and the version ranges affected by the vulnerability, and filters and enriches the data by combining contextual information such as the business system to which the asset belongs, the management responsible party, and the security partition, ultimately generating a detailed list of affected assets containing business context.

[0059] In step S400, a security response instruction is generated from the list of affected assets and sent to the security protection system according to the preset response strategy.

[0060] Based on a pre-defined response strategy knowledge base, which defines handling rules for different business criticality levels, vulnerability severity, and asset environments, after receiving the list of affected assets generated in step S300, the response urgency of each asset in the list is calculated, and specific, executable security response instructions are automatically generated based on the strategy knowledge base. These instructions may include isolating network segments, issuing virtual patches, scheduling vulnerability remediation work orders, or triggering security device policy updates. The generated instructions are automatically sent to the corresponding security protection devices or operation and maintenance management platforms for execution through standard API interfaces, forming a closed loop from analysis to action.

[0061] By automatically standardizing the processing of multi-source heterogeneous intelligence, analyzing asset associations and impacts based on knowledge graphs, and generating automated strategies and issuing instructions, a complete and efficient vulnerability management closed loop has been built. This significantly improves the efficiency and accuracy of the entire process from vulnerability disclosure to response and handling, reduces excessive reliance on human experience, and can adapt to the urgent needs of complex modern IT environments, especially in the field of critical information infrastructure, for precise prevention and rapid response.

[0062] Specifically, in step S300, the vulnerability description information is traversed and queried based on the asset knowledge graph to identify the list of affected assets, including:

[0063] Step S310: Parse the vulnerability description information and extract the software components related to the vulnerability and their version range as the vulnerability impact range parameter.

[0064] The structured vulnerability description information obtained after standardization in step S100 is subjected to in-depth analysis. This process comprehensively utilizes Natural Language Processing (NLP) technology and predefined key information extraction rules to accurately identify and extract the software component identifiers involved in the vulnerability and their exact version impact range. Specifically, the parsing engine first performs word segmentation, entity recognition, and relation extraction on the description text to locate key fields such as "affected components" and "affected versions." Then, for the various expressions that may exist in the version description (e.g., "from version 1.0.0 to version 1.1.1e", "all versions from 1.x series to 2.14.1", "versions below 2.15.0"), a rule engine and syntax parser are used to normalize them into a unified, machine-comparable version range representation (such as a version number list, closed / open interval description). Finally, the extracted software component names (such as "OpenSSL", "Apache Log4j"), precise version impact ranges (such as "[1.0.0,1.1.1e]", "(-∞,2.14.1]"), and other relevant constraints are assembled into a set of structured vulnerability impact range parameters, providing clear and unambiguous query input for subsequent knowledge graph-based asset retrieval.

[0065] Step S320: Using the vulnerability impact range parameter as the starting query condition, perform a multi-hop traversal query in the asset knowledge graph. The multi-hop traversal query is passed along the edges representing dependencies and deployment relationships in the asset knowledge graph to obtain IT asset objects that are directly installed or indirectly dependent on software components.

[0066] Using the software component name from the structured vulnerability impact scope parameter extracted in step S310 as a key query seed, precise matching and positioning are performed in the graph database to quickly determine the corresponding node entity of the component in the asset knowledge graph. This process typically leverages the graph's indexing mechanism (such as attribute-based indexing or full-text indexing) to achieve efficient querying, ensuring rapid target location even among massive asset nodes.

[0067] After successfully locating the vulnerable component node, the first phase of graph traversal is initiated. This phase starts from the vulnerable component node and performs a reverse traversal along predefined edges representing software dependencies in the knowledge graph (the edge type can be identified as "depends_on" or "requires"). This reverse traversal aims to discover all upper-layer application, library, or other software module nodes that structurally and explicitly depend on this component. The traversal process can be implemented using recursive queries written in standard graph query languages ​​(such as Cypher or Gremlin), and the traversal depth can be configured to control the search scope, thereby efficiently aggregating all direct and indirect software dependency assets to form a preliminary set of software layer assets.

[0068] After completing the reverse traversal of software dependencies, the second phase of graph traversal is initiated. This phase uses all software layer asset nodes (such as application nodes) acquired in the previous phase as a new starting point and proceeds forward along the edges representing deployment relationships in the knowledge graph (these edges can be identified as "deployed_on", "hosted_on", or "runs_on"). This traversal aims to map software entities to the physical or virtual infrastructure on which they run, thereby locating the actual computing environment nodes that ultimately host this software, such as physical servers, virtual machine instances, container pods, or cloud hosts. Through these two phases and the continuous traversal along two different types of relationship edges, a complete chain discovery from the vulnerable component to all potentially affected infrastructure is achieved.

[0069] Finally, all infrastructure nodes reached during the second phase of traversal are aggregated, and duplicates are eliminated to form a complete set of IT asset objects to be verified. This set includes assets that have the affected version components directly installed, as well as assets that are indirectly related through dependency chains and may also face the same risks, providing a comprehensive target scope for the precise version verification in the subsequent step S330.

[0070] Step S330: Match and verify the version information and version range of IT asset objects, and select asset nodes whose versions fall within the affected range as the initial set of affected assets.

[0071] Obtain the set of IT asset objects obtained from the graph traversal in step S320, and initiate the precise version verification process for the relevant software components on each asset node in the set. This process first obtains the actual installed version information of the target software component on the asset by calling a pre-built asset detection agent, querying the configuration management database (CMDB), or parsing the software manifest details pre-stored in the asset knowledge graph. Since version information from different sources may have issues such as diverse formats and non-standard naming (e.g., "v1.2.3", "1.2.3-release", "Build_1234"), a unified version cleaning and standardization engine needs to be called to parse, complete, and reconstruct the original version string according to the semantic versioning (SemVer) specification, converting it into a standard format that can be used for precise comparison (e.g., "1.2.3").

[0072] After version standardization is completed, the standardized version value is matched with the vulnerability impact range parameter (i.e., the structured version range) parsed in step S310. This matching process is based on a pre-defined version range matching algorithm, which can handle complex logical conditions including closed ranges, open ranges, infinite ranges, and combinations of multiple ranges, and accurately determine whether a specific version falls within the affected range. This matching operation is performed on each asset node in the asset set, and the matching result is recorded.

[0073] For asset nodes where precise version numbers cannot be obtained due to historical reasons or special environmental conditions, or where version numbers do not exist at all (e.g., firmware for certain embedded devices), an auxiliary verification mechanism will be activated for secondary judgment. This mechanism mainly includes two approaches: First, by comparing whether the build timestamp of the component file falls within a specific time period after the vulnerability disclosure, it can be inferred whether the asset may contain an affected version; Second, by calculating the file hash value (e.g., SHA-256) of a specific component on the asset and comparing it with a list of file hash values ​​of known affected versions obtained from trusted intelligence sources, the asset's impact can be determined based on the matching results (especially under high trust weights).

[0074] Asset nodes confirmed solely through the aforementioned primary version matching mechanism or any auxiliary verification mechanism will be aggregated and deduplicated to form a preliminary set of affected assets. This will provide verified, high-confidence foundational data for subsequently adding business attributes and generating the final list.

[0075] Step S340: Combining the pre-set business attribute information in the asset knowledge graph, dynamically associate each asset node in the initial set of affected assets with its own business system, management person in charge, and security criticality level, and generate a list of affected assets containing business context information.

[0076] Based on the pre-defined extended attributes in the constructed asset knowledge graph, the initial set of affected assets generated in step S330 is subjected to in-depth association and enrichment of business context. This process retrieves the associated static attributes and dynamic relationship data in batches by calling the attribute query interface of the graph and using the unique identifier of the asset node as the key.

[0077] Specifically, each asset node is associated with the name of its affiliated business system (e.g., "distribution automation system," "electricity metering system"), the team or individual responsible for the system's operation and maintenance, the network security zone where the asset is located (e.g., production control zone, management information zone), and the criticality level (e.g., core, important, general) pre-determined based on business impact assessments. Furthermore, it can be further associated with power grid-specific attributes such as the physical substations served by the asset, voltage levels, and the distribution lines or feeders it belongs to.

[0078] Through an automated attribute mapping and association engine, the aforementioned scattered business attribute information is integrated with the preliminary technology list to generate a structured final list of affected assets that includes both technical and business impact dimensions. This list not only records the technical identifiers and version verification results of the assets, but also details their business affiliation, management responsibility, security zone, and criticality level, providing a comprehensive decision-making basis for subsequent risk assessment and accurate formulation of response strategies.

[0079] Furthermore, step S320, which uses the vulnerability impact scope parameter as the starting query condition, performs a multi-hop traversal query in the asset knowledge graph, including:

[0080] Step S321: Use the software components in the vulnerability impact range parameter as query seed nodes and locate them in the asset knowledge graph. The query seed node is the starting point for traversal query.

[0081] Receive the structured vulnerability impact parameters passed from step S310. These parameters contain the core vulnerability characteristics information after precise parsing and standardization. First, extract the key software component identifiers from these parameters. These identifiers are usually the standardized names of the software components (e.g., "OpenSSL", "Apache Log4j"), and in some cases may also contain specific vendor information or globally unique identifiers (e.g., PURL) to ensure accuracy in subsequent graph queries.

[0082] After extracting the component identifier, it is used as the core query key to locate nodes within a pre-built and continuously updated asset knowledge graph. This query process heavily relies on the efficient indexing mechanism of the graph database. Various index types are typically used to accelerate this search process, such as:

[0083] Attribute Index: Directly index the "Name" attribute on nodes of the "Software Component" type to achieve precise matching queries at the millisecond level.

[0084] Full-text index: Used to handle possible name variations or spelling similarities, improving query recall.

[0085] Hybrid index: Combines component name with other attributes (such as "manufacturer") for joint queries to ensure excellent query performance even in high concurrency or ultra-large-scale graphs.

[0086] After executing the query, all graph nodes that precisely match the given component identifier are returned. These successfully matched nodes are formally established as the "query seed nodes" for this multi-hop graph traversal, forming the unique starting point set for the entire impact analysis process. The accuracy and efficiency of this step are crucial, providing a precise and undisputed starting point for the recursive traversal along dependencies and deployment relationships in subsequent steps S322 and S323, ensuring the correctness of the entire asset impact chain tracing process.

[0087] Step S322: Starting from the query seed node, perform a reverse traversal along the dependency edges that represent the dependencies between software components. The reverse traversal is to obtain all upstream application nodes that directly depend on the software components in the opposite direction of the dependency relationship.

[0088] Step S322: After successfully locating the query seed node representing the vulnerability component in the asset knowledge graph, the first phase of graph traversal is initiated. This traversal process aims to reveal all upper-level software entities that directly or indirectly depend on this component. Its core is to perform a reverse traversal along the predefined edges in the graph that represent the dependencies between software components (the edge types can be explicitly defined in the graph model as such as "depends_on", "requires", or "uses").

[0089] The reverse traversal here refers to a specific direction in graph queries, where the traversal direction is opposite to the natural direction of dependencies. Typically, the natural direction of dependency edges is from the "dependent party" (e.g., an application) to the "depended party" (e.g., an underlying library). Reverse traversal, however, starts from the "depended party" (i.e., the seed node of the vulnerability component in this case) and moves backward along the edge to discover all "dependent party" nodes that depend on it. This traversal is implemented using graph query languages ​​(such as "<-[:DEPENDS_ON]-" in Cypher or ".in("depends_on")" in Gremlin) and is usually configured as a recursive query (e.g., using "variable-length path queries") to discover not only direct dependencies but also indirect, multi-level dependencies (e.g., application A depends on framework B, and framework B depends on vulnerability library C).

[0090] This process is particularly important in specific implementations within the power industry. For example, when a low-level communication library (such as "libwebsockets") is found to be vulnerable, performing a reverse dependency traversal using this component as a seed node might reveal that it is depended upon by a "substation equipment status monitoring service," which in turn is called by a higher-level "regional power grid monitoring platform." By configuring an appropriate traversal depth (e.g., 3 to 5 hops) and setting filtering conditions (e.g., excluding deprecated test environment nodes), all applications, services, and middleware nodes that depend on the vulnerable component in the software architecture can be automatically and comprehensively aggregated, forming a complete set of software layer assets for further analysis. This lays the foundation for locating the physical carrier assets in subsequent step S323.

[0091] Step S323: Starting from all discovered nodes, including upstream application nodes, traverse along the deployment edges representing deployment relationships to determine the physical host or cloud server nodes that carry software components, and obtain a set of IT asset objects.

[0092] Step S323 follows the output of the previous stage (S322), using the set of all discovered software layer nodes with dependencies as the input and starting point for this stage. The second stage of graph traversal then begins. The core objective of this stage is to map abstract software logical dependencies to concrete, locatable physical or virtual infrastructure assets, thereby achieving precise placement from logical influence to physical assets. This stage strictly follows the forward traversal of predefined directed edges representing deployment relationships in the knowledge graph. These edges are typically standardized and labeled as "deployed_on", "hosted_on", or "runs_on", and their direction points from the software entity to the infrastructure entity it deploys.

[0093] Each node in the software node set obtained in the first phase is used as an independent traversal starting point. The iterator is configured to move only along outgoing edges of the specific type mentioned above, ensuring that the traversal path is strictly limited to the scope of deployment relationships. The traversal process supports configuring multiple hops to adapt to multi-layered deployment architectures common in modern IT environments, such as the layered mapping from microservices to Kubernetes Pods, then to Worker Nodes, and finally to cloud virtual machine instances. It will recursively follow these deployment edges until no new infrastructure nodes are found or the preset maximum number of hops is reached. This number of hops can be flexibly adjusted according to the complexity of the infrastructure layers.

[0094] During the traversal, all infrastructure entity nodes accessed through deployment edges are collected and maintained in a dynamic set. These node types broadly cover modern data center architectures, including physical servers, network devices, virtual machines, container instances, Kubernetes Pods, cloud server instances, and more. For complex scenarios where the same software entity is deployed across multiple infrastructure nodes (such as cluster deployments), the traversal comprehensively discovers all relevant targets, ensuring the completeness of the impact scope analysis. It can also integrate weight or priority logic (such as based on environment tags) to provide a basis for subsequent differentiated processing.

[0095] After this stage of traversal is completed, the final set of infrastructure nodes represents all specific assets that directly or indirectly have the vulnerable component or its dependent components installed. These assets are the core target objects for the next step of precise version verification and vulnerability existence confirmation. For example, in the power industry, a "smart meter data acquisition service" that relies on the vulnerability library OpenSSL may be mapped to specific Docker containers, Kubernetes Pods, and physical servers through multi-hop traversal.

[0096] The steps described above successfully extended vulnerability impact analysis from the software component level to the hardware and operating environment level, generating an accurate list of infrastructure assets to be verified, providing crucial input data for operations and security teams to carry out precise remediation actions.

[0097] Further, in step S330, the version information of the IT asset object is matched and verified with the version range to filter out asset nodes whose versions fall within the affected range as a preliminary set of affected assets, including:

[0098] Step S331: Extract the asset version information corresponding to each asset node in the IT asset object set. The asset version information includes the software version number, build timestamp, and / or version identifier.

[0099] As the initial step in the version verification process, step S331 extracts the precise version identifier information corresponding to each asset node from the set of IT asset objects obtained in the previous graph traversal. This process is achieved through a multi-source data acquisition mechanism: first, it queries the pre-set node attribute fields in the asset knowledge graph (such as metadata directly stored in the form of version, build_number, etc.). If the attribute fields do not contain valid version information, it triggers a dynamic data acquisition process—obtaining asset registration information through the API interface of the integrated configuration management database (CMDB), or calling the acquisition agent deployed in the target environment to read the software feature data of the running system in real time. The extracted version information encompasses three dimensions: first, the software version number, which may be presented as a semantic version (e.g., "2.3.1"), generation number (e.g., "v4.2"), or a mixed name (e.g., "Release-2023Q4"); second, the build timestamp, typically using the ISO 8601 standard format or Unix timestamps to record the compilation and deployment time; and third, unique identifiers, including commit hashes (e.g., "a1b2c3d"), package build IDs (e.g., the Release field of an RPM), or Docker image digests. For special types of assets (e.g., containerized microservices), it is also necessary to parse their associated image repository metadata or orchestration templates (e.g., Kubernetes YAML files) to supplement the version context. All extracted raw data will be structured and stored in a temporary validation database to provide input for subsequent standardization processing stages.

[0100] Step S332: Standardize and parse the software version number and convert it into a unified format that conforms to the semantic versioning specification.

[0101] Step S332 is crucial for standardizing the extracted raw version data. Its core objective is to address the heterogeneity of version naming rules caused by differences in software vendors, open-source projects, or packaging methods, thus establishing a unified benchmark for subsequent accurate version comparison. This process is achieved through a built-in multi-pattern version parsing engine: First, the engine selects the most matching parsing strategy from a pre-built parsing rule library (including common standards such as SemVer, date version, PythonPEP 440, and Maven version specifications) based on context such as software name and vendor information. For version strings that cannot be automatically matched, a heuristic algorithm is used to identify and extract numeric sequences, letter tags, and delimiters through regular expression pattern matching.

[0102] Specific standardization operations include: syntax cleaning (removing prefixes and suffixes such as "v" and "release-" and descriptive text), structural reconstruction (rearranging the identified numerical sequences according to priority for major version number, minor version number, and revision number, automatically padding missing bits with zeros), and special identifier processing (converting pre-release tags such as "beta" and "rc1" to SemVer-compatible hyphenated format, and retaining build metadata at the end of the standardized version string). For example, the original version "v2.1.3-release" is normalized to "2.1.3", "20230412" is parsed into a date version and converted to "2023.4.12", while "1.5.2+build.abc123" is retained as "1.5.2+abc123".

[0103] To ensure conversion accuracy, a validity check is performed on each standardized result: the version segment is checked to ensure it is a non-negative integer, the pre-release tag conforms to the specification, and outliers that cannot be parsed (such as the plain text version "latest") are marked as parsing failures. All standardized version strings are output in a unified semantic versioning format and associated with the original version data for auditing and traceability, ultimately forming a standardized version data set that can be used for precise comparison.

[0104] Step S333: Based on semantic version comparison rules, the standardized software version number is matched with the version range in the vulnerability impact range parameter through a version matching mechanism to determine whether it falls within the start and end version range of the vulnerability impact.

[0105] Step S333 bears the core responsibility of version matching verification. At this stage, the standardized asset version is precisely matched with the vulnerability's impact scope. This process is based on the comparison rules defined in the Semantic Versioning Specification (SemVer) and is executed by a dedicated version matching engine. The matching engine first parses the version constraints defined in the vulnerability impact scope parameter. These constraints may be presented in various forms: including continuous intervals (such as closed intervals [1.5.0, 2.0.0], open intervals (1.2.0, 1.7.0], or half-open / half-closed intervals), combinations of multiple discontinuous intervals (such as "<1.0.0||>=2.3.0, <2.5.0"), and even complex logical expressions (such as ">=1.0.0<1.5.7!=1.4.3").

[0106] During the matching process, an optimization algorithm based on interval trees is used to quickly locate whether an asset version falls within the affected interval. For each standardized asset version, the engine compares it with all defined affected intervals, strictly following the semantic version priority rules: first, the major version number is compared, then the minor version number, and finally the revision number. Special handling is given to the matching logic of pre-release versions (such as 1.0.0-alpha) and build metadata (such as 1.0.0+build.001)—pre-release versions are usually considered unstable versions and need to be explicitly declared for matching, while build metadata does not affect version priority but needs to be recorded.

[0107] To improve matching accuracy, a version metadata context-aware mechanism is also integrated. For example, when encountering a version range definition containing ambiguous boundaries (such as "all 2.x versions"), it will automatically expand to a precise range of [2.0.0, 3.0.0). When dealing with software from different release channels (such as stable and long-term support versions), differentiated matching will be performed based on version tags. All matching results are accompanied by a confidence rating, with precise version matching receiving the highest confidence, while results derived from version ranges are annotated with the reasoning behind the derivation.

[0108] Step S334: For asset nodes that cannot obtain a valid software version number or whose version number does not conform to the semantic versioning specification, verification is performed through an auxiliary matching mechanism. The auxiliary matching mechanism makes a judgment by comparing whether the build timestamp is within a specific time period after the vulnerability disclosure time, or by verifying whether the file hash value matches the file hash value of the known affected version.

[0109] Step S334 specifically handles special scenarios involving missing or abnormal version information, ensuring the completeness of vulnerability impact assessment by enabling a multi-dimensional auxiliary matching mechanism. When an asset node is detected to lack a valid version number, have an unparseable version format, or have obviously unreliable version information, a three-level verification process will be automatically triggered.

[0110] The first level is based on time window-based build timestamp analysis. First, the build timestamp of the asset is obtained (extracted from CI / CD pipeline records, image metadata, or file attributes), and then correlated with the vulnerability disclosure time (CVE release date) and the release time of the first patch. A dynamic time window model is established, with the window starting at the vulnerability disclosure time and the end point dynamically adjusted according to the characteristics of the software project. For active projects, it may be set to 30 days after disclosure, while for projects with long maintenance cycles, it may be extended to 90 days. If the asset's build time falls within this window period, it is marked as "suspected to be affected," and the time-match confidence level is recorded.

[0111] The second level employs precise file-level hash value comparison. Cryptographic hash values ​​(preferably SHA-256 algorithm) of critical asset files are obtained through proxy collection or remote commands. These files include: binary executables, dynamic link libraries (.so / .dll), core configuration files, and software package signature files. Comparison data sources include: the list of affected version file hashes published by the National Vulnerability Database (NVD), official hash index tables provided by software vendors, and a self-built hash knowledge base (accumulated through historical scans). To improve efficiency, a Bloom filter is used for rapid initial screening, followed by precise matching of candidate files.

[0112] The third level involves context-based verification. If the situation remains unresolved, the associated context of the asset node is analyzed: checking for other version instances of the same software component in adjacent nodes, retrieving installation records from package manager databases (such as rpm / yum, dpkg, npm), and even using code snippet feature matching (e.g., for open-source components) for further assistance.

[0113] All conclusions derived through auxiliary mechanisms are labeled with a clear confidence level (high / medium / low), and the verification methods and data sources are recorded. A detailed auxiliary verification report is generated, including the time window parameters used, the number of hash values ​​compared, the list of matching files, and the contextual analysis results, providing a complete basis for subsequent manual auditing.

[0114] Step S335: Merge the asset nodes confirmed by the version matching mechanism with the asset nodes confirmed by the auxiliary matching mechanism, and obtain a preliminary set of affected assets after deduplication.

[0115] Step S335, as the integration phase of the version verification process, is responsible for systematically fusing and deduplicating the matching results generated in the previous steps. This phase first fuses data from two input sources: one is the set of asset nodes confirmed by the precise version matching mechanism in S333, and the other is the set of asset nodes verified by the auxiliary matching mechanism in S334. A joint query operation based on the globally unique identifier (UUID) of the nodes is used to perform a full outer join on the two sets, retaining all asset nodes verified as affected through any path.

[0116] During the deduplication process, a multi-dimensional deduplication strategy is implemented: First, basic deduplication is performed based on the master node ID to eliminate completely duplicate node records; second, for composite assets with multiple version instances (such as multiple replica Pods in a container cluster), an "asset fingerprint" matching algorithm (combining IP address, hostname, asset type, and other attributes to generate a unique fingerprint) is used for cross-node aggregation; finally, for the same asset node generated through different verification paths (such as those that pass both version matching and hash verification), the record with the most sufficient verification evidence is retained, and all verification metadata is merged.

[0117] After deduplication, each asset node in the set is labeled with a verification source identifier (version matching / timestamp matching / hash matching / hybrid verification) and a confidence score (based on the reliability of the verification method). Complete verification trajectory data is retained, including key audit information such as the version range rules used, the matching time window parameters, and the number of hash values ​​compared. The final preliminary set of affected assets is output in a standardized JSON format, containing basic asset information, verification results, confidence ratings, and citations of the original verification evidence. This data is then pushed to the downstream vulnerability priority assessment module and patch management system via API.

[0118] Further, step S334, which involves verifying whether the file hash value matches the file hash value of a known affected version, includes:

[0119] Step S3341: Obtain the file hash value of the known affected version from a preset trusted security intelligence source.

[0120] Data is automatically collected from multiple authoritative security intelligence sources via API interfaces, including the National Vulnerability Database (NVD), vendor security bulletins, GitHub security announcements, and third-party vulnerability intelligence platforms (such as Snyk and VulnDB). During the collection process, data sources of different formats (such as CVE JSON format, STIX / TAXII standard format, or custom XML format) are parsed to extract the file hash information contained therein (usually SHA-256 or MD5 values), and the CVE number, affected software version range, and vulnerability severity level corresponding to each hash value are recorded. To ensure data integrity, a timed polling mechanism (usually executed every 2 hours) and a manual update trigger function are also set up to ensure that the latest vulnerability intelligence data can be obtained in a timely manner.

[0121] Step S3342: Perform multi-source cross-validation and cleaning / deduplication on the file hash values, construct a dynamically updated polluted file hash library, and attach a source credibility weight and a recent update timestamp to each record.

[0122] First, hash values ​​from multiple sources are deduplicated to eliminate duplicate records between different intelligence sources. Then, data cleaning is performed to remove malformed hash values ​​and expired records (based on the expiration timestamps provided by the intelligence sources). For cases where multiple hash values ​​exist for the same file, a source credibility assessment algorithm is used to assign weights: hash values ​​directly provided by the vendor have a weight of 1.0, those from authoritative third-party platforms have a weight of 0.8, and those from community sources have a weight of 0.5. Finally, a structured polluted file hash library is generated. Each record contains a hash value, corresponding CVE number, weight value, last update timestamp, and data source identifier. This hash library is stored in a key-value database format and provides a high-speed query interface.

[0123] Step S3343: Obtain the current file hash value of the corresponding software node in the IT asset object set.

[0124] Connecting to the IT assets to be verified via a collection agent or remote management protocol (such as SSH or WinRM) deployed in the target environment, the system executes appropriate hash collection commands based on the asset type: for Linux systems, the `sha256sum` command is used to calculate the hash value of files at a specified path; for Windows systems, the `Get-FileHashPowerShell` command is used; and for container environments, internal commands are executed via `docker exec` or `kubectlexec`. The collection scope covers key components such as core executable files, dynamic link libraries, and configuration files, while recording the collection time, file path, and calculated hash value to form a file hash list of the current asset.

[0125] Step S3344: Compare the current file hash value with the records in the polluted file hash database, and obtain the verification result of whether they match based on the matching result and the credibility weight of the corresponding record.

[0126] The collected list of current file hashes is batch-compared with records in the contaminated file hash database. A Bloom filter is used for rapid initial screening, followed by a precise comparison of candidate matches. When a match is found, a verification result is generated based on the record's credibility weight: matches with a weight higher than 0.7 are directly marked as "confirmed to be affected"; matches with a weight between 0.4 and 0.7 are marked as "suspected to be affected" and prompted for manual review; matches with a weight lower than 0.4 are considered false matches and excluded. All matching results are accompanied by complete evidence chain information, including the matched hash value, source intelligence, weight value, and collection time, forming an auditable verification report.

[0127] This file hash verification mechanism, based on multi-source intelligence integration and weight evaluation, can maintain a high vulnerability detection accuracy even in the absence of clear version information, significantly reducing the risk of false negatives due to missing version information. At the same time, the credibility weight classification effectively controls the false positive rate, providing reliable technical support for subsequent security response decisions.

[0128] Furthermore, after generating the list of affected assets containing business context information in step S340, the process also includes:

[0129] Step S351: After generating security response instructions based on the list of affected assets, extract the vulnerability identifier corresponding to the current vulnerability intelligence, the common feature patterns of assets in the list of affected assets, and the type of security response instructions used to generate historical analysis knowledge entries.

[0130] After generating security response instructions, the entire processing flow is automatically analyzed, extracting key information from three dimensions: First, the vulnerability's own characteristic identifiers, including CVE number, CVSS score, affected product type, and version range pattern; second, the common characteristics of affected assets, identifying common attributes such as operating system type, software framework, and deployment mode through cluster analysis; and finally, the type of security response instruction used and its parameter configuration, such as specific operation instructions for patch application, configuration modification, and network isolation. These elements are structured to form historical analysis knowledge entries. Each record contains three parts: a vulnerability feature vector, an asset impact pattern fingerprint, and a response instruction template, along with metadata such as a timestamp and information on the personnel handling the issue.

[0131] Step S352: Store the historical analysis knowledge entries in the historical analysis knowledge base, which stores the analysis and response data of all handled vulnerabilities.

[0132] The generated historical analysis knowledge entries are persistently stored in a specially designed historical analysis knowledge base. This knowledge base employs a multimodal storage architecture, using a graph database to store the association between vulnerabilities and asset characteristics, a time-series database to record processing data, and a relational database to maintain complete knowledge entry metadata. The knowledge base implements version control, supporting the tracing and evolution analysis of historical entries. It also establishes a hot data caching mechanism based on access frequency, providing a fast, memory-level access interface for frequently used knowledge entries. The knowledge base also features a regular maintenance mechanism that automatically cleans up outdated entries and updates existing knowledge with confidence-weighted updates based on new processing results.

[0133] Step S353: Analyze the newly received vulnerability intelligence to obtain its vulnerability impact range parameter and perform similarity correlation calculation with the vulnerability characteristics and asset impact patterns of all historical analysis knowledge entries in the historical analysis knowledge base to obtain a comprehensive similarity score.

[0134] When new vulnerability intelligence arrives, its impact scope parameters are first analyzed to extract key attributes such as vulnerability technical characteristics, affected component types, and version constraints. Then, through feature vectorization, the features of the new vulnerability are converted into a computable numerical representation, and multi-dimensional similarity calculations are performed with all entries in the historical analysis knowledge base: including vulnerability feature similarity (comparing vulnerability description texts based on natural language processing), impact pattern similarity (comparing the distribution characteristics of affected asset types), and version range similarity (comparing the degree of overlap in version constraints). Finally, a weighted fusion algorithm is used to obtain a comprehensive similarity score, with weights dynamically adjusted based on the processing success rate and confidence level of historical entries.

[0135] Step S354: If the comprehensive similarity score between the vulnerability impact scope parameter and a historical analysis knowledge entry exceeds a preset similarity threshold, then the security response instruction corresponding to the historical analysis knowledge entry is invoked, and the threat level and handling priority of the newly received vulnerability intelligence are increased.

[0136] When the overall similarity between a new vulnerability and a historical knowledge entry exceeds a preset threshold (usually set to 0.85), a knowledge reuse mechanism is automatically triggered: First, the verified security response instructions corresponding to the historical entry are invoked and recommended to security analysts as the priority handling plan for the new vulnerability. Simultaneously, based on historical handling effectiveness data, the threat level and handling priority of the new vulnerability are automatically increased, shortening the emergency response time. A correlation link between the new and old vulnerabilities is also established, supporting comparative analysis of differences and adjustments to response strategies. All automated decisions are recorded in audit logs for subsequent verification and optimization.

[0137] By establishing this intelligent response mechanism based on the reuse of historical knowledge, the response speed and consistency of similar vulnerabilities can be significantly improved, and repetitive analysis work can be reduced. At the same time, through continuous knowledge accumulation and optimization, an organization-specific vulnerability response knowledge system can be gradually built, thereby improving the maturity and efficiency of overall security operations.

[0138] Specifically, in step S400, a security response instruction is generated from the list of affected assets based on a preset response strategy, including:

[0139] Step S410: Based on the business criticality level, vulnerability threat level, and real-time network traffic situation information of each asset node in the affected asset list, create a multi-dimensional decision vector.

[0140] First, business attribute data for each asset node is extracted from the list of affected assets. This includes the business criticality level (typically categorized as core, important, and general) obtained from the CMDB, and the vulnerability threat level (high-, medium-, and low-risk based on CVSS scoring) obtained from the vulnerability database. Real-time situational information (including current network connection status, abnormal traffic characteristics, and the number of recent security incidents) is also integrated from the network traffic analysis system. After standardization, this data is used to construct a three-dimensional decision vector for each asset, comprising a business impact factor, a vulnerability severity index, and a network exposure index. Each dimension uses a normalized numerical representation (range 0-1) for subsequent quantitative calculations.

[0141] Step S420: Process the multidimensional decision vector based on the response decision model to obtain the corresponding quantitative response urgency score for each asset node.

[0142] The response decision model employs a weighted scoring algorithm, assigning different weight coefficients (e.g., 0.4, 0.3, 0.3) to business criticality level, vulnerability threat level, and network posture indicators. These weights can be dynamically adjusted according to the organization's security strategy. The model first calculates standardized scores for each dimension, then uses a weighted summation formula to obtain a response urgency score (0-100 points) for each asset. To improve assessment accuracy, the model also introduces a time decay factor, appropriately reducing the weight of network anomalies with longer durations while assigning higher sensitivity to newly emerging attack activities. The final urgency score is divided into four levels on a 100-point scale: Critical (80-100 points), High (60-79 points), Medium (30-59 points), and Low (0-29 points).

[0143] Step S430: Based on the quantitative response urgency score, obtain the response actions matching each level from the response action library to obtain the corresponding safety response instructions.

[0144] Maintain a tiered response action library, containing response actions matched to each urgency level: Emergency level triggers instructions to immediately isolate the network and suspend services; High level triggers instructions to prioritize patch deployment and enhance monitoring; Medium level triggers planned remediation and routine monitoring instructions; Low level only generates security alerts. The instruction generation process also considers the specific environmental characteristics of the assets; for example, a more cautious response strategy may be adopted for production environment assets, while a more aggressive approach may be used for test environment assets. All generated instructions undergo pre-verification checks to ensure compatibility with existing security policies and that they will not cause business interruption.

[0145] This response instruction generation mechanism, based on multi-dimensional assessment and quantitative scoring, enables precise and differentiated handling of security responses. It ensures rapid containment of high-risk situations while avoiding over-processing of low-risk assets, effectively improving the efficiency and accuracy of security operations. At the same time, standardized processes reduce the subjectivity and inconsistency of human judgment.

[0146] Furthermore, step S420, which processes the multidimensional decision vector based on the response-based decision model, includes:

[0147] Step S421: Obtain a set of historical vulnerability handling records. For each historical handling record in the set, extract the historical multidimensional decision vector from the historical handling record as the basic feature. Extract the topological clustering degree and business dependency density information of the assets affected by the vulnerability from the asset knowledge graph related to the historical handling record as the enhanced feature. Fuse the basic feature and the enhanced feature to form the input feature of the corresponding training sample of the historical handling record, and obtain the enhanced historical multidimensional decision vector.

[0148] Complete handling records are extracted from the historical vulnerability handling record database. For each record, a basic multidimensional decision vector is first extracted, including standardized data such as asset business criticality level, vulnerability threat level, and network posture indicators. Then, the asset knowledge graph snapshot at the time the historical handling record was generated is traced back, and graph computing algorithms are used to extract the topological features of the assets affected by the vulnerability. This includes calculating the asset's topological clustering degree (using local clustering coefficients to measure the degree of asset clustering in the network) and business dependency density (assessing the strength of its business association by analyzing the number of dependency connections between the asset and other business nodes). These topological features are fused with the basic features to form an enhanced historical multidimensional decision vector. This vector not only includes the asset's own attributes but also incorporates its contextual relationship information within the overall IT environment, providing the model with a more comprehensive decision-making basis.

[0149] Step S422: Based on the repair time, impact index on business service availability, and probability value of successfully blocking the attack, the comprehensive effect score of the response action is calculated and used as the training target for the training sample.

[0150] Based on historical performance data, three key performance indicators (KPIs) are calculated: remediation time (the time from vulnerability discovery to complete remediation, standardized after logarithmic transformation), business impact index (calculated by combining the degree of service availability degradation and the number of affected users recorded by the monitoring system), and successful blocking probability (statistically based on the successful blocking of related attack events in subsequent security monitoring data). These three KPIs are weighted and fused to generate a comprehensive performance score, with weighting coefficients configured according to organizational preferences (e.g., organizations prioritizing business continuity may assign a higher weight to the business impact index). All KPI data are normalized, and the resulting comprehensive performance score serves as the training target for supervised learning.

[0151] Step S423: Use the enhanced historical multidimensional decision vectors of all training samples as input features, and their corresponding comprehensive performance scores as training targets. Use machine learning algorithms to train the model and obtain the response decision model.

[0152] The model is trained using enhanced feature vectors from all historical disposal records as input features and corresponding comprehensive performance scores as output labels. During training, feature selection is performed first, removing features with low relevance. Then, the data is standardized and sample weights are adjusted (assigning higher weights to recent samples). For model selection, algorithms capable of handling high-dimensional features and with good interpretability, such as Gradient Boosting Decision Tree (GBDT) or Random Forest, are typically used. Hyperparameters are optimized through cross-validation and grid search. After training, the model is deployed as a callable service, providing model performance monitoring and a mechanism for periodic retraining.

[0153] This model training method, based on historical data, can learn the complex mapping relationship between multi-dimensional features and response effects, thereby generating a more scientific and accurate response urgency score, significantly improving the quality and efficiency of security response decisions, and continuously optimizing decision-making capabilities through a continuous learning mechanism.

[0154] Accordingly, a second aspect of the present invention provides an electronic device, including: at least one processor; and a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processor to perform the above-described method for the collection, analysis and utilization of vulnerability intelligence throughout its entire lifecycle.

[0155] Accordingly, a third aspect of the present invention provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the above-described method for the collection, analysis, and utilization of vulnerability intelligence throughout its entire lifecycle.

[0156] This invention aims to protect a method for the coordinated collection, analysis, and exploitation of vulnerability intelligence throughout its entire lifecycle, achieving the following effects:

[0157] 1. By constructing a knowledge graph that integrates the complex dependencies and deployment relationships of power assets, and by performing intelligent multi-hop traversal queries and multi-dimensional version verification (including file hash verification) based on vulnerability intelligence, the drawbacks of traditional manual methods, such as low efficiency and easy errors, are overcome. It can automatically, quickly and accurately locate the specific power equipment, business systems and their related links affected by vulnerabilities, greatly improving the comprehensiveness and accuracy of risk identification and providing a reliable basis for subsequent response.

[0158] 2. By constructing a decision-making model that integrates multiple dimensions such as business criticality level, vulnerability threat, and real-time situation, and combining it with a historical experience knowledge base for similarity matching and optimization, it can output differentiated and quantitative response strategies for power assets of different importance and in different scenarios, ensuring a high degree of adaptability and synergy between security measures and business continuity requirements, and achieving the optimal balance between security benefits and operational benefits.

[0159] 3. The complete process, results, and contextual characteristics of each vulnerability handling are accumulated into historical analysis knowledge entries, and a rapid reuse mechanism based on similarity calculation is constructed. By utilizing the accumulated experience and knowledge, new vulnerabilities are quickly assessed and response recommendations are made. This not only significantly accelerates the response speed to repeated or similar threats, but also improves the overall maturity and automation level of the security operation system, and realizes continuous self-optimization of system processing efficiency.

[0160] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0161] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxesFigure 1 A device that provides the functions specified in one or more boxes.

[0162] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0163] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0164] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for the integrated collection, analysis, and utilization of vulnerability intelligence throughout its entire lifecycle, characterized in that: Includes the following steps: Raw vulnerability intelligence from multiple heterogeneous data sources is obtained, and the raw vulnerability intelligence is standardized to obtain vulnerability description information. Construct an asset knowledge graph, which is used to represent IT asset objects within the enterprise and the dependencies and deployment relationships between these IT asset objects; Based on the asset knowledge graph, the vulnerability description information is traversed and queried to identify the list of affected assets affected by the vulnerability; Based on the preset response strategy, a security response command is generated from the list of affected assets and sent to the security protection system.

2. The method for the coordinated collection, analysis, and utilization of vulnerability intelligence throughout its entire lifecycle, as described in claim 1, is characterized in that... The step of performing a graph traversal query on the vulnerability description information based on the asset knowledge graph to identify the list of affected assets impacted by the vulnerability includes: Parse the vulnerability description information and extract the vulnerability-related software components and their version ranges as parameters for the vulnerability's impact scope. Using the vulnerability impact range parameter as the starting query condition, a multi-hop traversal query is performed in the asset knowledge graph. The multi-hop traversal query is passed along the edges representing dependencies and deployment relationships in the asset knowledge graph to obtain IT asset objects that are directly installed or indirectly dependent on the software components. Based on the version information of the IT asset object, the version range is matched and verified to select asset nodes whose versions fall within the affected range as a preliminary set of affected assets. By combining the pre-set business attribute information in the asset knowledge graph, each asset node in the initial set of affected assets is dynamically associated with its own business system, management person in charge, and security criticality level, generating a list of affected assets containing business context information.

3. The method for the coordinated collection, analysis, and utilization of vulnerability intelligence throughout its entire lifecycle, as described in claim 2, is characterized in that... The step of performing a multi-hop traversal query in the asset knowledge graph, using the vulnerability impact range parameter as the starting query condition, includes: The software components in the vulnerability impact range parameter are used as query seed nodes and located in the asset knowledge graph. The query seed node is the starting point for traversal query. Starting from the query seed node, a reverse traversal is performed along the dependency edges that represent the dependencies between software components. The reverse traversal is to obtain all upstream application nodes that directly depend on the software component in the opposite direction of the dependency relationship. Starting from all discovered nodes, including upstream application nodes, traverse along the deployment edges representing deployment relationships to determine the physical host or cloud server node that carries the software component, thus obtaining the set of IT asset objects.

4. The method for the coordinated collection, analysis, and utilization of vulnerability intelligence throughout its entire lifecycle, as described in claim 2, is characterized in that... The step of matching and verifying the version information of the IT asset object with the version range to filter out asset nodes whose versions fall within the affected range as a preliminary set of affected assets includes: Extract the asset version information corresponding to each asset node in the IT asset object set. The asset version information includes the software version number, build timestamp, and / or version identifier. The software version number is standardized and parsed, and converted into a unified format that conforms to the semantic versioning specification; Based on semantic version comparison rules, the standardized software version number is matched with the version range in the vulnerability impact range parameter through a version matching mechanism to determine whether it falls within the start and end version range of the vulnerability impact. For asset nodes for which a valid software version number cannot be obtained or whose version number does not conform to the semantic versioning specification, verification is performed through an auxiliary matching mechanism. The auxiliary matching mechanism makes a judgment by comparing whether the build timestamp is within a specific time period after the vulnerability disclosure time, or by verifying whether the file hash value matches the file hash value of the known affected version. The asset nodes confirmed through the version matching mechanism are merged with the asset nodes confirmed through the auxiliary matching mechanism, and after deduplication, the preliminary set of affected assets is obtained.

5. The method for the coordinated collection, analysis, and utilization of vulnerability intelligence throughout its entire lifecycle, as described in claim 4, is characterized in that... The step of verifying whether the file hash value matches the file hash value of a known affected version includes: Obtain the file hash values ​​of known affected versions from a pre-set trusted security intelligence source; The file hash values ​​are subjected to multi-source cross-validation and cleaning and deduplication to construct a dynamically updated polluted file hash library, and each record is appended with a source credibility weight and a recent update timestamp; Obtain the current file hash value of the corresponding software node in the IT asset object set; The current file hash value is compared with the records in the polluted file hash database, and a verification result of whether a match is obtained based on the matching result and the credibility weight of the corresponding record.

6. The method for the coordinated collection, analysis, and utilization of vulnerability intelligence throughout its entire lifecycle, as described in claim 2, is characterized in that... After generating the list of affected assets containing business context information, the process also includes: After generating security response instructions based on the affected asset list, extract the vulnerability identifier corresponding to the current vulnerability intelligence, the common feature patterns of assets in the affected asset list, and the type of security response instructions used to generate historical analysis knowledge entries. The historical analysis knowledge entries are stored in the historical analysis knowledge base, which stores the analysis and response data of all handled vulnerabilities. The newly received vulnerability intelligence is analyzed to obtain its vulnerability impact range parameter. It is then compared with the vulnerability characteristics and asset impact patterns of all historical analysis knowledge entries in the historical analysis knowledge base to calculate the comprehensive similarity score. If the combined similarity score between the vulnerability impact range parameter and a historical analysis knowledge entry exceeds a preset similarity threshold, then the security response instruction corresponding to the historical analysis knowledge entry is invoked, and the threat level and handling priority of the newly received vulnerability intelligence are increased.

7. The method for the coordinated collection, analysis, and utilization of vulnerability intelligence throughout its entire lifecycle, as described in any one of claims 1-6, is characterized in that... The step of generating security response instructions from the list of affected assets based on a preset response strategy includes: A multi-dimensional decision vector is created based on the business criticality level, vulnerability threat level, and real-time network traffic situation information of each asset node in the affected asset list. The multidimensional decision vector is processed based on the response decision model to obtain a quantitative response urgency score for each asset node. Based on the quantitative response urgency score, response actions matching each level are obtained from the response action library, resulting in corresponding safety response instructions.

8. The method for the coordinated collection, analysis, and utilization of vulnerability intelligence throughout its entire lifecycle, as described in claim 7, is characterized in that... The processing of the multidimensional decision vector based on the response decision model includes: A set of historical vulnerability handling records is obtained. For each historical handling record in the set, the historical multidimensional decision vector in the historical handling record is extracted as a basic feature. The topological clustering degree and business dependency density information of the assets affected by the vulnerability are extracted from the asset knowledge graph related to the historical handling record as enhanced features. The basic features and the enhanced features are fused to form the input features of the corresponding training samples of the historical handling record, and the enhanced historical multidimensional decision vector is obtained. Based on the repair time, impact index on business service availability, and probability value of successfully blocking the attack of the corresponding response action in the historical handling records, the comprehensive effect score of the response action is calculated and used as the training target of the training sample. Using the enhanced historical multidimensional decision vectors of all the training samples as input features and their corresponding comprehensive performance scores as training targets, the model is trained using machine learning algorithms to obtain the response decision model.

9. An electronic device, characterized in that, include: At least one processor; And a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processor to perform the linked method for collection, analysis and exploitation of vulnerability intelligence throughout its entire lifecycle as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, It stores computer instructions, which, when executed by a processor, implement the method for the collection, analysis, and utilization of vulnerability intelligence throughout its entire lifecycle as described in any one of claims 1-8.

Images