Vulnerability CPE identification method and device, equipment and storage medium

Abstract

The invention discloses a vulnerability CPE identification method and device, equipment and a storage medium. Firstly, a to-be-recognized vulnerability original text and multi-source vulnerability auxiliary information can be obtained, and the multi-source vulnerability auxiliary information comprises data related to vulnerability information published by an NVD official website and a third-party vulnerability organization and manufacturer security announcements. Performing key information extraction on the vulnerability original text to obtain vulnerability entity information, and converting the vulnerability entity information into a vector form to obtain a query vector; performing vector retrieval in a pre-constructed CPE knowledge base on the basis of the query vector to obtain a plurality of candidate CPE characters, and generating an identification cue word on the basis of the candidate character strings, the vulnerability original text and the multi-source vulnerability auxiliary information. And taking the recognition cue word as input, and performing semantic understanding and multi-source information fusion reasoning through a CPE recognition model to obtain a plurality of CPE character strings. According to the invention, the integrity and accuracy of CPE information extraction are improved, and the understanding of related dependency relationships of vulnerabilities is enhanced.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, specifically to a method, apparatus, device, and storage medium for identifying vulnerability CPEs. Background Technology

[0002] Currently, vulnerability CPE extraction primarily relies on advanced natural language processing (NLP) technologies. The core objective is to accurately identify and extract Common Platform Enumeration (CPE) related information from the vulnerability source text. In this application scenario, due to their mature performance, certain typical extraction models are widely adopted. Their core function is to directly extract explicitly presented entity information from the text, thereby completing the initial CPE extraction.

[0003] However, because these models lack deep inference capabilities based on semantic logic, they cannot capture CPEs that are not explicitly stated in the text but are closely related to the vulnerability. This type of potential information is often deeply tied to the vulnerability's triggering conditions, system dependencies, or underlying operational logic. For example, a vulnerability might depend on a specific operating system version, hardware architecture, underlying libraries, or deployment components, but this critical information is often not directly mentioned in the vulnerability description. Therefore, CPEs generated by traditional extraction methods are often incomplete and have relatively limited coverage. This limitation not only reduces the overall understanding of the vulnerability but may also affect the security team's assessment of potential risks when developing response strategies.

[0004] Therefore, how to more comprehensively capture potential CPE information related to vulnerabilities is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a method, apparatus, device, and storage medium for identifying vulnerability CPEs, which can improve the completeness and accuracy of CPE information extraction and enhance the understanding of vulnerability-related dependencies.

[0006] The embodiments of this application disclose the following technical solutions:

[0007] A method for identifying vulnerable CPEs, the method comprising:

[0008] Obtain the original vulnerability text to be identified, as well as multi-source vulnerability auxiliary information; the multi-source vulnerability auxiliary information includes data on vulnerability information released by the National Vulnerability Database (NVD) website and third-party vulnerability organizations, as well as vendor security announcements;

[0009] The vulnerability entity information is obtained by extracting key information from the original vulnerability text, and the vulnerability entity information is converted into a vector form to obtain a query vector;

[0010] Based on the query vector, vector retrieval is performed in a pre-built general platform enumeration CPE knowledge base to obtain multiple candidate CPE strings;

[0011] Based on the multiple candidate CPE strings, the vulnerability text, and the multi-source vulnerability auxiliary information, generate CPE identification prompt words;

[0012] Using the CPE identification prompt words as input, semantic understanding and multi-source information fusion reasoning are performed through the CPE identification model to obtain multiple CPE strings.

[0013] In one possible implementation, the extraction of key information from the vulnerability source text to obtain vulnerability entity information includes:

[0014] The BERT-MRC algorithm model is used to extract the triple information consisting of vendor, product, and version from the vulnerability original text, which is used as the vulnerability entity information.

[0015] In one possible implementation, the construction process of the CPE knowledge base includes:

[0016] Acquire various types of basic data related to vulnerability information; these basic data include historical CPE dictionaries, vendor product dictionaries, component dependency lists, and hardware-operating system compatibility tables.

[0017] Each piece of data in the aforementioned multiple types of basic data is vectorized to obtain multiple basic data vectors;

[0018] Establish a correspondence between each basic data vector and its corresponding original data text to obtain multiple vector-original text mapping pairs;

[0019] The CPE knowledge base is obtained by organizing multiple vector-text mapping pairs into a mapping table.

[0020] In one possible implementation, the vector retrieval is performed based on the query vector in a pre-built CPE knowledge base to obtain multiple candidate CPE strings, including:

[0021] In the CPE knowledge base, basic data vectors with a similarity greater than a similarity threshold are queried as candidate vectors.

[0022] The original data text corresponding to the candidate vector is used as the candidate CPE string.

[0023] In one possible implementation, the method further includes:

[0024] Each CPE string is mapped to a seven-tuple consisting of vendor, product, version, update, edition, sw_edition, target_sw, target operating system, target_hw, and language, resulting in multiple structured CPE data.

[0025] Each structured CPE data point was standardized according to the standard CPE format specification to obtain multiple vulnerability CPE data.

[0026] A vulnerability CPE identification device, the device comprising:

[0027] The first acquisition unit is used to acquire the original text of the vulnerability to be identified, as well as multi-source vulnerability auxiliary information; the multi-source vulnerability auxiliary information includes data on vulnerability information released by the NVD official website and third-party vulnerability organizations, as well as vendor security announcements;

[0028] The information extraction unit is used to extract key information from the vulnerability original text to obtain vulnerability entity information.

[0029] An information conversion unit is used to convert the vulnerability entity information into a vector form to obtain a query vector.

[0030] The retrieval unit is used to perform vector retrieval in a pre-built CPE knowledge base based on the query vector to obtain multiple candidate CPE strings;

[0031] The prompt word generation unit is used to generate CPE identification prompt words based on the multiple candidate CPE strings, the vulnerability original text, and the multi-source vulnerability auxiliary information;

[0032] The recognition unit is used to take the CPE recognition prompt words as input, and perform semantic understanding and multi-source information fusion reasoning through the CPE recognition model to obtain multiple CPE strings.

[0033] In one possible implementation, the information extraction unit is specifically used for:

[0034] The BERT-MRC algorithm model is used to extract the triple information consisting of vendor, product, and version from the vulnerability original text, which is used as the vulnerability entity information.

[0035] In one possible implementation, the device further includes:

[0036] The second acquisition unit is used to acquire multiple types of basic data related to vulnerability information; the multiple types of basic data include historical CPE dictionary, vendor product dictionary, component dependency list and hardware-operating system compatibility table.

[0037] A vectorization unit is used to vectorize each piece of data in the multiple types of basic data to obtain multiple basic data vectors.

[0038] The mapping pair construction unit is used to establish a correspondence between each basic data vector and its corresponding original data, resulting in multiple vector-original text mapping pairs;

[0039] The sorting unit is used to sort multiple vector-text mapping pairs into a mapping table to obtain the CPE knowledge base.

[0040] A vulnerability CPE identification device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the vulnerability CPE identification method as described above.

[0041] A computer-readable storage medium storing instructions that, when executed on a terminal device, cause the terminal device to perform the vulnerability CPE identification method as described above.

[0042] Compared with the prior art, this application has the following beneficial effects:

[0043] This application provides a method, apparatus, device, and storage medium for identifying vulnerability CPEs. Specifically, when executing the vulnerability CPE identification method provided in this application, the original vulnerability text to be identified and its related multi-source vulnerability auxiliary information can be collected first. This auxiliary information includes data from the National Vulnerability Database (NVD) website, vendor security bulletins, and vulnerability information released by third-party vulnerability organizations. This multi-source data not only provides a basic description of the vulnerability but also supplements key content such as official authoritative annotations and product dependencies, providing sufficient information support for identifying potentially related CPEs. Next, key information is extracted from the collected vulnerability text to extract vulnerability entity information, and this entity information is converted into vector form to generate a query vector. This vectorization process helps improve the accuracy and efficiency of subsequent retrieval. Further, based on the generated query vector, vector retrieval is performed in a pre-built CPE knowledge base to obtain multiple candidate CPE strings. Then, by combining the candidate CPE strings, the vulnerability text, and the multi-source vulnerability auxiliary information, CPE identification prompts are generated. The generation of prompts provides an important basis for subsequent semantic understanding and reasoning. The generated CPE identification prompts are then used as input, and semantic understanding and multi-source information fusion reasoning are performed through the CPE identification model to finally obtain multiple CPE strings. This not only captures explicitly presented entity information, but also captures related CPE information that is not explicitly stated in the text but is closely related to the vulnerability through deep reasoning, thereby improving the completeness and accuracy of CPE information extraction.

[0044] This application not only obtains the original vulnerability text to be identified, but also integrates multi-source auxiliary information on vulnerabilities from the NVD official website, vendor security announcements, and third-party vulnerability organizations. This covers the basic description of the vulnerability and supplements it with key additional content such as official authoritative annotations and product dependencies, providing ample information support for identifying potentially related CPEs. Simultaneously, vector retrieval in a pre-built CPE knowledge base can quickly obtain multiple candidate CPE strings. This method is more flexible and accurate than traditional keyword matching, and can find relevant CPE information in a wider range. Furthermore, CPE identification prompts generated based on candidate CPE strings, vulnerability texts, and auxiliary information further enrich the model's input information and improve the model's performance in semantic understanding and reasoning processes. Attached Figure Description

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

[0046] Figure 1 A flowchart illustrating a vulnerability CPE identification method provided in this application embodiment;

[0047] Figure 2 A flowchart illustrating a CPE knowledge base construction method provided in this application embodiment;

[0048] Figure 3 This is a schematic diagram of a vulnerability CPE identification device provided in an embodiment of this application. Detailed Implementation

[0049] To facilitate understanding of the technical solutions provided in the embodiments of this application, the background technology involved in the embodiments of this application will be described below.

[0050] Currently, vulnerability CPE extraction primarily relies on advanced natural language processing (NLP) technologies. The core objective is to accurately identify and extract CPE-related information from the original vulnerability text. In this application scenario, the BERT-MRC (BERT-based Machine Reading Comprehension) model, also known as the BERT (Bidirectional Encoder Representation) machine reading comprehension model, is widely adopted due to its mature performance. As a typical extraction model, its core function is to directly extract explicitly presented entity information from the text, thereby completing the initial CPE extraction.

[0051] However, because the model lacks deep inference capabilities based on semantic logic, it cannot capture CPEs that are not explicitly stated in the text but are closely related to the vulnerability. This potential information is often deeply tied to the vulnerability's triggering conditions, system dependencies, or underlying operational logic. Therefore, CPEs generated by traditional extraction methods are often incomplete and have relatively limited coverage. This limitation not only reduces the comprehensive understanding of the vulnerability but may also affect the security team's assessment of potential risks when developing response strategies.

[0052] To address this issue, this application provides a method, apparatus, device, and storage medium for identifying vulnerability CPEs. First, the system acquires the original vulnerability text to be identified and integrates auxiliary information from multiple sources, including data from the NVD website, security advisories released by vendors, and relevant information provided by third-party vulnerability organizations. This integration of multi-source information lays the foundation for comprehensive vulnerability analysis. Next, the system extracts key information from the acquired vulnerability text, extracting vulnerability entity information and converting it into vector form to generate a query vector. The key to this process is efficiently capturing important information implicit in the text and providing a structured representation for subsequent retrieval. Then, based on this query vector, the system performs vector retrieval in a pre-built CPE knowledge base to obtain multiple candidate CPE strings. Compared to traditional keyword search, this retrieval method can find vulnerability-related CPE information more flexibly and accurately. After obtaining the candidate CPE strings, the system further generates CPE identification prompts by combining the vulnerability text and multi-source auxiliary information. These prompts, as input, are used for deep semantic understanding and information fusion reasoning through a CPE identification model, ultimately outputting multiple related CPE strings. This application enhances the understanding of vulnerability-related dependencies, thereby providing more comprehensive information support for identifying potentially associated CPE information, which helps to more accurately assess potential risks and develop effective response strategies.

[0053] The technical solutions in the embodiments of the present invention have been clearly and completely described. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0054] See Figure 1 The figure is a flowchart of a vulnerability CPE identification method provided in an embodiment of this application, as shown below. Figure 1 As shown, the vulnerability CPE identification method may include steps S101-S105:

[0055] S101: Obtain the original text of the vulnerability to be identified, as well as auxiliary information on vulnerabilities from multiple sources.

[0056] To overcome the limitations of traditional CPE vulnerability identification, which relies solely on single text messages, and to ensure sufficient authoritative evidence and supplementary materials for the identification process, the first step is to obtain the original vulnerability text to be identified. This lays the core foundation for extracting basic CPE information. Simultaneously, multi-source vulnerability auxiliary information is systematically integrated, including authoritative records published on the National Vulnerability Database (NVD) website, relevant information disclosed by third-party vulnerability organizations, and official security announcements issued by the product vendor regarding the vulnerability. This comprehensive aggregation of multi-dimensional information provides all-round data support for the subsequent accurate discovery of explicit CPEs and potentially related CPEs.

[0057] S102: Extract key information from the vulnerability original text to obtain vulnerability entity information, and convert the vulnerability entity information into vector form to obtain query vector.

[0058] To build the core foundation for subsequent accurate retrieval, the original vulnerability text needs to undergo structured preprocessing: Vulnerability entity information is extracted and refined through key information extraction. Specifically, the BERT-MRC (BERT-based machine reading comprehension) algorithm model is used to accurately locate and extract triples consisting of vendor, product, and version from the original vulnerability text. These triples serve as the core vulnerability entity information. This structured vulnerability entity information is then further converted into a machine-computable and comparable vector form, ultimately yielding a query vector for retrieval and matching. This provides technical support for efficient matching of relevant information in the CPE knowledge base.

[0059] In one possible implementation, the extraction of key information from the vulnerability source text to obtain vulnerability entity information includes:

[0060] The BERT-MRC algorithm model is used to extract the triple information consisting of vendor, product, and version from the vulnerability original text, which is used as the vulnerability entity information.

[0061] S103: Based on the query vector, perform vector retrieval in the pre-built CPE knowledge base to obtain multiple candidate CPE strings.

[0062] Based on the query vectors obtained in the early stage, semantic vector retrieval is initiated in the pre-built CPE knowledge base. By leveraging the advantages of vector similarity calculation, the dependence of traditional keyword matching on literal expression is broken through. Multiple CPE related information that are highly related to the semantics of the current vulnerability is accurately located and filtered out. Finally, multiple candidate CPE strings can be used for subsequent reasoning, which narrows down the scope and locks in the core clues for comprehensively identifying vulnerability-related CPEs.

[0063] S104: Generate CPE identification prompts based on the multiple candidate CPE strings, the vulnerability original text, and the multi-source vulnerability auxiliary information.

[0064] To fully leverage the semantic understanding and logical reasoning capabilities of the CPE identification model and avoid identification bias or incomplete coverage issues caused by a single information source, it is necessary to structurally integrate multi-dimensional key information to generate CPE identification prompts. For example, "You are a cybersecurity expert. Based on vulnerability-related information (vulnerability text, multiple candidate CPE strings, data on vulnerability information released by NVD official website and third-party vulnerability organizations, and vendor security bulletins), output all CPE strings affected by the vulnerability in the form of a JSON list. (The operating system, hardware, or components on which the affected products depend need to be considered.)" This clarifies the model's core task and output requirements while providing sufficient reasoning basis for the model, ensuring that it can comprehensively capture explicit CPEs and potentially related CPEs.

[0065] Specifically, the generation of prompt words should be based on the original vulnerability text (to ensure the relevance of the identification and fit the core vulnerability scenario), with multiple candidate CPE strings as core clues (to narrow down the range of highly relevant basic CPEs), and supplemented by multi-source vulnerability auxiliary information (NVD official website data, vendor security announcements, third-party vulnerability database summaries, etc.) as supporting evidence (providing authoritative annotations, dependencies, triggering conditions, and other key reasoning basis). The model should be guided by clear instructions to focus on the core objective of "identifying all affected CPEs (including the main product and its dependent operating systems, hardware, and components)" and then perform model reasoning.

[0066] S105: Using the CPE recognition prompt words as input, semantic understanding and multi-source information fusion reasoning are performed through the CPE recognition model to obtain multiple CPE strings.

[0067] After inputting CPE identification prompts that integrate multi-dimensional key information into the CPE identification model, the model first initiates a deep semantic understanding process. This process accurately analyzes the core triggering logic of the vulnerability text, the associations between candidate CPE strings, and key details such as authoritative annotations and dependencies in multi-source auxiliary information, achieving a deep deconstruction and understanding of the dispersed information. Subsequently, leveraging the model's multi-source information fusion and reasoning capabilities, it breaks through the limitations of a single information source, organically linking vulnerability scenarios, candidate clues, and supplementary evidence. This not only identifies explicitly mentioned main product-related CPEs from the vulnerability text but also deduces potential CPEs (such as dependent operating systems, hardware architectures, and underlying components) closely related to the vulnerability triggering, based on clues such as dependencies and operating environments in the auxiliary information. Through layers of logical verification and association filtering, the model ultimately outputs multiple complete strings covering the main CPE and potential related CPEs, ensuring that the identification results are both consistent with the actual vulnerability scenario and possess comprehensiveness and reliability.

[0068] In one possible implementation, the CPE identification model can be the AI ​​model "Llama", with parameters set as temperature=0.3, top_p=0.95, repetition penalty=1.05, and max_new_tokens=512.

[0069] Based on the content of S101-S105, the process begins with comprehensively collecting the original vulnerability texts to be identified, and simultaneously integrating multi-source vulnerability auxiliary information from the NVD official website, vendor security announcements, and third-party vulnerability organizations to ensure the completeness and authority of the information coverage. Next, key information is extracted from the vulnerability texts, and the core vulnerability entity information is refined and converted into a vector query vector, laying the foundation for subsequent accurate retrieval. Subsequently, based on this query vector, vector retrieval is performed in a pre-built CPE knowledge base to quickly match and obtain multiple highly relevant candidate CPE strings. Then, the aforementioned candidate CPE strings, vulnerability texts, and multi-source vulnerability auxiliary information are fused to construct targeted CPE identification prompts, achieving structured integration of scattered information. Finally, these prompts are input into the CPE identification model, and through the model's semantic understanding capabilities and multi-source information fusion reasoning mechanism, multiple accurately corresponding CPE strings are output, completing the comprehensive identification of vulnerability CPEs. This application enhances the understanding of vulnerability-related dependencies, thereby providing more comprehensive information support for identifying potentially related CPE information, helping to more accurately assess potential risks and formulate effective response strategies.

[0070] In one possible implementation, such as Figure 2 As shown, the construction process of the CPE knowledge base includes steps S201-S204:

[0071] S201: Obtain various types of basic data related to vulnerability information.

[0072] To build a CPE knowledge base with high coverage and strong relevance, the first step is to comprehensively collect multiple types of core foundational data deeply related to vulnerability information, specifically covering four key categories: First, a historical CPE dictionary, which contains a massive number of standardized CPE entries, providing a unified CPE format and authoritative benchmark for the knowledge base; second, a vendor product dictionary, containing the names of mainstream vendors in various industries and a complete list of their products (including Chinese and English aliases, version naming rules, etc.), effectively solving the problem of inconsistent vendor and product name descriptions; third, a component dependency list, recording the hierarchical dependencies between software and hardware components, providing crucial dependency logic support for discovering potential CPEs associated with vulnerabilities; and fourth, a hardware-operating system compatibility table, clarifying the compatibility relationships between different hardware architectures and operating systems, helping the knowledge base cover CPEs related to the underlying operating environment affected by vulnerabilities. By integrating the above multi-dimensional data, the content foundation of the CPE knowledge base can be guaranteed, laying a solid foundation for subsequent vector retrieval and precise matching.

[0073] S202: Vectorize each piece of data in the multiple types of basic data to obtain multiple basic data vectors.

[0074] To achieve semantic retrieval and matching of basic data, standardized vectorization processing is required for the collected basic data of various types. For each standard CPE entry in the historical CPE dictionary, each set of manufacturer-product name correspondences in the manufacturer product dictionary, each component association record in the component dependency list, and each adaptation data in the hardware-operating system compatibility table, a unified text vector conversion model is used for encoding. The original unstructured or semi-structured text information is mapped into numerical vectors with semantic representation capabilities in a high-dimensional space. Finally, multiple basic data vectors corresponding one-to-one with each basic data are obtained, providing technical support for subsequent fast retrieval and accurate matching based on vector similarity.

[0075] S203: Establish a correspondence between each basic data vector and its corresponding original data to obtain multiple vector-original text mapping pairs.

[0076] To ensure accurate source tracing and prevent the vectors from becoming disconnected from the original data, each basic data vector obtained after vectorization needs to be associated with its original text data. In the historical CPE dictionary, a single CPE standard entry vector corresponds to its original text entry; in the manufacturer product dictionary, a single manufacturer-product name vector corresponds to its original name combination; in the component dependency list, a single component association record vector corresponds to its original dependency description; and in the hardware-operating system compatibility table, a single adaptation data vector corresponds to its original adaptation information. This results in multiple clearly structured vector-text mapping pairs that retain the semantic computational attributes of the vectors while binding them to the actual business meaning of the original data. This provides reliable support for quickly reconstructing the corresponding CPE-related information after subsequent vector similarity-based retrieval.

[0077] S204: Organize multiple vector-text mapping pairs into a mapping table to obtain the CPE knowledge base.

[0078] To create a standardized and manageable CPE knowledge base, the previously constructed vector-text mapping pairs need to be systematically integrated and organized into a structured mapping table according to unified indexing rules. This table uses basic data vectors as the core retrieval index and the corresponding original text data as the associated content, achieving both precise binding between vectors and original text and supporting rapid querying and matching based on vector semantic similarity. Through this structured approach, the scattered mapping pairs are transformed into a knowledge base with a unified access interface. This not only efficiently supports candidate CPE vector retrieval in the subsequent vulnerability CPE identification process but also ensures that search results can be directly traced back to the original basic data, providing solid underlying data support for the accuracy and reliability of CPE identification.

[0079] The process of establishing the CPE knowledge base through steps S201-S204 effectively integrates information from multiple sources, enhances the understanding of vulnerability-related products and their dependencies, and provides important support for security management.

[0080] In one possible implementation, the vector retrieval is performed based on the query vector in a pre-built general platform enumeration CPE knowledge base to obtain multiple candidate CPE strings, including:

[0081] In the CPE knowledge base, basic data vectors with a similarity greater than or equal to a similarity threshold are retrieved as candidate vectors. Then, the original data text corresponding to the candidate vectors is used as candidate CPE strings.

[0082] Specifically, the process of retrieving multiple candidate CPE strings from a pre-built CPE knowledge base based on query vectors must be carried out systematically using the core logic of vector semantic similarity matching: First, a reasonable similarity threshold is set (this threshold can be dynamically adjusted according to actual retrieval accuracy requirements). Then, in the mapping table of the CPE knowledge base, the semantic similarity between the query vector and all basic data vectors in the database is calculated one by one, and basic data vectors with similarity values ​​greater than the preset threshold are selected and marked as candidate vectors. Next, based on the pre-established one-to-one correspondence between vectors and original text in the knowledge base, the original text data bound to all candidate vectors is extracted. Finally, this original text data is directly used as candidate CPE strings that are highly relevant to the current vulnerability, providing accurate and highly relevant material support for subsequent generation of CPE identification prompts and multi-source information fusion reasoning.

[0083] In one possible implementation, the method further includes:

[0084] Each CPE string is mapped to a seven-tuple consisting of vendor, product, version, update, edition, sw_edition, target_sw (target operating system), target_hw (target hardware architecture), and language, resulting in multiple structured CPE data sets. Then, each structured CPE data set is standardized according to the standard CPE format specification to obtain multiple vulnerability CPE data sets.

[0085] Specifically, to further improve the standardization and reusability of CPE data, this application also includes a structured and standardized processing flow for the identification results: First, the output CPE strings are decomposed dimensionally and mapped into a nine-tuple structure consisting of vendor, product, version, update, edition, sw_edition, target_sw, target_hw, and language, forming multiple structured CPE data with clear semantic dimensions. Then, using SemVer regular expressions and a manual rule base (e.g., normalizing "1.8.0_311" to "1.8.0:update311"), the format of each set of structured CPE data is calibrated and content is completed, ultimately yielding multiple vulnerability CPE data that conform to industry standards and can be directly used for vulnerability correlation analysis and asset matching.

[0086] In one possible implementation, during the process of "mapping each CPE string into a seven-tuple consisting of vendor, product, version, update, edition, sw_edition, target_sw, target operating system, target_hw, and language to obtain multiple structured CPE data", if any fields are missing, the missing fields are filled with "*" or "-".

[0087] See Figure 3 , Figure 3 This is a schematic diagram of a vulnerability CPE identification device provided in an embodiment of this application. Figure 3 As shown, the vulnerability CPE identification device includes:

[0088] The first acquisition unit 301 is used to acquire the original text of the vulnerability to be identified, as well as multi-source vulnerability auxiliary information; the multi-source vulnerability auxiliary information includes data on vulnerability information released by the NVD official website and third-party vulnerability organizations, as well as vendor security announcements;

[0089] The information extraction unit 302 is used to extract key information from the vulnerability original text to obtain vulnerability entity information.

[0090] Information conversion unit 303 is used to convert the vulnerability entity information into a vector form to obtain a query vector;

[0091] The retrieval unit 304 is used to perform vector retrieval in a pre-built CPE knowledge base based on the query vector to obtain multiple candidate CPE strings;

[0092] The prompt word generation unit 305 is used to generate CPE identification prompt words based on the multiple candidate CPE strings, the vulnerability original text, and the multi-source vulnerability auxiliary information;

[0093] The recognition unit 306 is used to take the CPE recognition prompt words as input, and perform semantic understanding and multi-source information fusion reasoning through the CPE recognition model to obtain multiple CPE strings.

[0094] In one possible implementation, the information extraction unit is specifically used for:

[0095] The BERT-MRC algorithm model is used to extract the triple information consisting of vendor, product, and version from the vulnerability original text, which is used as the vulnerability entity information.

[0096] In one possible implementation, the device further includes:

[0097] The second acquisition unit is used to acquire multiple types of basic data related to vulnerability information; the multiple types of basic data include historical CPE dictionary, vendor product dictionary, component dependency list and hardware-operating system compatibility table.

[0098] A vectorization unit is used to vectorize each piece of data in the multiple types of basic data to obtain multiple basic data vectors.

[0099] The mapping pair construction unit is used to establish a correspondence between each basic data vector and its corresponding original data, resulting in multiple vector-original text mapping pairs;

[0100] The sorting unit is used to sort multiple vector-text mapping pairs into a mapping table to obtain the CPE knowledge base.

[0101] In one possible implementation, the retrieval unit 304 is specifically used for:

[0102] In the CPE knowledge base, basic data vectors with a similarity greater than a similarity threshold are queried as candidate vectors.

[0103] The original data text corresponding to the candidate vector is used as the candidate CPE string.

[0104] In one possible implementation, the device further includes:

[0105] The mapping unit is used to map each CPE string to a seven-tuple consisting of vendor, product, version, update, edition, sw_edition, target_sw, target operating system, target_hw, and language, to obtain multiple structured CPE data.

[0106] The standardization unit is used to standardize each structured CPE data according to the standard CPE format specification to obtain multiple vulnerability CPE data.

[0107] In addition, this application embodiment also provides a vulnerability CPE identification device, including: a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, it implements the vulnerability CPE identification method as described above.

[0108] In addition, this application embodiment also provides a computer-readable storage medium storing instructions that, when executed on a terminal device, cause the terminal device to perform the vulnerability CPE identification method as described above.

[0109] This application's embodiments obtain the original vulnerability text to be identified and integrate multi-source auxiliary information from the NVD official website, vendor security announcements, and third-party vulnerability organizations. This multi-source data not only covers the basic description of the vulnerability but also supplements key content such as official authoritative annotations and product dependencies, providing ample information support for identifying potentially related CPEs. Simultaneously, this application can quickly obtain multiple candidate CPE strings through vector retrieval in a pre-built CPE knowledge base. Compared to traditional keyword matching methods, this vector retrieval approach is more flexible and accurate, capable of finding relevant CPE information across a wider range. Furthermore, CPE identification prompts generated based on candidate CPE strings, vulnerability text, and auxiliary information further enrich the model's input information, covering not only explicitly presented entity information but also capturing related CPE information closely associated with the vulnerability but not explicitly stated in the text through deep reasoning. This significantly improves the model's performance in semantic understanding and multi-source information fusion reasoning, thereby enhancing the completeness and accuracy of CPE information extraction.

[0110] The foregoing provides a detailed description of a vulnerability CPE identification method, apparatus, device, and storage medium provided in this application. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

[0111] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0112] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A vulnerability CPE identification method, characterized by, The method comprises: obtaining a vulnerability original text to be identified and multi-source vulnerability auxiliary information; the multi-source vulnerability auxiliary information comprises data about vulnerability information published by a national vulnerability database (NVD) official website and a third-party vulnerability organization, and a vendor security announcement; performing key information extraction on the vulnerability original text to obtain vulnerability entity information, and converting the vulnerability entity information into a vector form to obtain a query vector; performing vector retrieval in a pre-constructed common platform enumeration (CPE) knowledge base based on the query vector to obtain a plurality of candidate CPE strings; generating a CPE identification prompt word based on the plurality of candidate CPE strings, the vulnerability original text and the multi-source vulnerability auxiliary information; inputting the CPE identification prompt word into a CPE identification model for semantic understanding and multi-source information fusion reasoning to obtain a plurality of CPE strings.

2. The method of claim 1, wherein, The key information extraction on the vulnerability original text to obtain the vulnerability entity information comprises: extracting a triple information composed of a vendor, a product and a version from the vulnerability original text by using a BERT-MRC algorithm model as the vulnerability entity information.

3. The method of claim 1, wherein, The construction process of the CPE knowledge base comprises: obtaining multi-class basic data related to vulnerability information; the multi-class basic data comprises a historical CPE dictionary, a vendor product dictionary, a component dependency list and a hardware-operating system compatibility table; vectorizing each piece of data in the multi-class basic data to obtain a plurality of basic data vectors; establishing a corresponding relationship between each basic data vector and its corresponding data original text to obtain a plurality of vector-original text mapping pairs; organizing the plurality of vector-original text mapping pairs into a mapping table to obtain the CPE knowledge base.

4. The method of claim 3, wherein, The vector retrieval in the pre-constructed CPE knowledge base based on the query vector to obtain the plurality of candidate CPE strings comprises: querying, in the CPE knowledge base, a basic data vector having a similarity greater than a similarity threshold to the query vector as a candidate vector; taking a data original text corresponding to the candidate vector as a candidate CPE string.

5. The method of claim 1, wherein, The method further comprises: mapping each CPE string into a seven-tuple composed of a vendor, a product, a version, an update, an edition type, a software version, a target operating system, a target hardware architecture and a language to obtain a plurality of structured CPE data; respectively standardizing each structured CPE data according to a standard CPE format specification to obtain a plurality of vulnerability CPE data.

6. A vulnerability CPE identification apparatus characterized by comprising: The device comprises: a first obtaining unit configured to obtain a vulnerability original text to be identified and multi-source vulnerability auxiliary information; the multi-source vulnerability auxiliary information comprises data about vulnerability information published by an NVD official website and a third-party vulnerability organization, and a vendor security announcement; an information extraction unit configured to perform key information extraction on the vulnerability original text to obtain vulnerability entity information; and An information conversion unit is configured to convert the vulnerability entity information into a query vector in a vector form; A retrieval unit is configured to perform vector retrieval in a pre-constructed CPE knowledge base based on the query vector, to obtain a plurality of candidate CPE strings; A prompt word generation unit is configured to generate a CPE identification prompt word based on the plurality of candidate CPE strings, the vulnerability original text, and the multi-source vulnerability auxiliary information; An identification unit is configured to take the CPE identification prompt word as input, and perform semantic understanding and multi-source information fusion reasoning through a CPE identification model, to obtain a plurality of CPE strings.

7. The apparatus of claim 6, wherein, The information extraction unit is specifically configured to: extract a triple information composed of vendor, product, and version from the vulnerability original text by using a BERT-MRC algorithm model, as the vulnerability entity information.

8. The apparatus of claim 6, wherein, The apparatus further includes: A second acquisition unit is configured to acquire multi-class basic data related to vulnerability information; the multi-class basic data includes a historical CPE dictionary, a vendor product dictionary, a component dependency list, and a hardware-operating system compatibility table; A vectorization unit is configured to vectorize each piece of data in the multi-class basic data, to obtain a plurality of basic data vectors; A mapping pair construction unit is configured to establish a corresponding relationship between each basic data vector and its corresponding data original text, to obtain a plurality of vector-original text mapping pairs; An arrangement unit is configured to arrange the plurality of vector-original text mapping pairs into a mapping table, to obtain the CPE knowledge base.

9. A vulnerability CPE identification device, characterized by, It includes: A memory, a processor, and a computer program stored on the memory and executable on the processor, and when the processor executes the computer program, the vulnerability CPE identification method in any one of claims 1-5 is implemented.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores instructions, and when the instructions run on the terminal equipment, the terminal equipment executes the vulnerability CPE identification method in any one of claims 1-5.

Images