A vulnerability query method, device, equipment and storage medium

By converting the vulnerability query method from mainly vulnerability to mainly version number, and using the target version vulnerability mapping table to directly obtain the vulnerability identifier, the problems of large communication overhead and low query efficiency in the existing technology are solved, and efficient vulnerability information query is achieved.

CN115292713BActive Publication Date: 2025-07-22NSFOCUS INFORMATION TECHNOLOGY CO LTD +1
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
CN202210893046.5
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-07-27
Publication Date
2025-07-22
Estimated Expiration
2042-07-27

AI Technical Summary

Technical Problem

When querying vulnerability information in the prior art, it is necessary to traverse all software assets-related vulnerabilities, resulting in large communication overhead and low query efficiency, especially in privacy query scenarios, which has a more significant impact.

Method used

Convert the vulnerability information query method from mainly vulnerability to mainly version number, and directly obtain all vulnerability identifiers of the target version number through the target version vulnerability mapping table to avoid traversing all vulnerability information, and use the target version vulnerability mapping table to summarize the vulnerability identifiers corresponding to each version number.

Benefits of technology

It reduces communication overhead and improves the efficiency of vulnerability information query, especially in the privacy query scenario, which significantly improves the computing efficiency of the user and server.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115292713B_ABST
    Figure CN115292713B_ABST
Patent Text Reader

Abstract

The present application provides a vulnerability query method, apparatus, device, and storage medium, which relate to the technical field of secure networks and are used to improve the query efficiency of vulnerability information while reducing communication overhead. The method includes: obtaining all vulnerability identifiers of the target version number from a target version vulnerability mapping table according to the target version number of the target system input by a user; wherein, the target system has at least one version number, the target version vulnerability mapping table is obtained by summarizing the vulnerability identifiers corresponding to each version number of the target system, and the target version vulnerability mapping table contains multiple pieces of data, all the vulnerability identifiers of the target version number are one piece of data in the target version vulnerability mapping table, and one vulnerability identifier corresponds to one type of vulnerability information.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the technical field of secure networks, and in particular, to a vulnerability query method, apparatus, device, and storage medium. Background Art

[0002] With the increasingly strict requirements for data security and the confidentiality of customer assets, providing basic version vulnerability queries to users in the form of privacy queries based on the vulnerability information database of security manufacturers themselves will become an increasingly important method in the future network security service field. However, currently, when querying based on the vulnerability data in the public vulnerability information database, the focus is on the vulnerabilities. Although this vulnerability information query method is convenient for maintaining vulnerability information, when querying the vulnerability information of a certain version of software assets, it is usually necessary to traverse all the vulnerabilities related to the software assets before determining the vulnerability information associated with the version. Moreover, a single asset vulnerability query request from a user may match multiple data records that meet the query conditions in the server database of the security manufacturer during privacy query, which will have a great impact on data communication and the computing efficiency of the user side and the server side, increase communication overhead, and reduce the query efficiency of vulnerability information. Summary of the Invention

[0003] Embodiments of this application provide a vulnerability query method, apparatus, device, and storage medium, which are used to improve the query efficiency of vulnerability information while reducing communication overhead.

[0004] In a first aspect, this application provides a vulnerability query method, which includes:

[0005] According to the target version number of the target system input by the user, obtain all the vulnerability identifiers of the target version number from the target version vulnerability mapping table; wherein, the target system has at least one version number, the target version vulnerability mapping table is obtained by summarizing the vulnerability identifiers corresponding to each version number of the target system, and the target version vulnerability mapping table contains multiple pieces of data. All the vulnerability identifiers of the target version number are one piece of data in the target version vulnerability mapping table, and one vulnerability identifier corresponds to one type of vulnerability information.

[0006] In an embodiment of the present application, the vulnerability information query method that "focuses on vulnerabilities" is converted into a vulnerability information query method that "focuses on version numbers". Furthermore, when querying vulnerability information, all vulnerability identifiers of the target version number can be directly obtained from the target version vulnerability mapping table according to the target version number of the target system input by the user. The target version vulnerability mapping table is obtained by summarizing the vulnerability identifiers corresponding to each version number of the target system, avoiding the need to traverse all to determine all vulnerability information of a certain version number in the prior art, greatly reducing the communication overhead, and improving the query efficiency of vulnerability information.

[0007] In a second aspect, the present application provides a vulnerability query device, the device includes:

[0008] A vulnerability identifier acquisition unit, configured to obtain all vulnerability identifiers of the target version number from the target version vulnerability mapping table according to the target version number of the target system input by the user; wherein, the target system has at least one version number, the target version vulnerability mapping table is obtained by summarizing the vulnerability identifiers corresponding to each version number of the target system, and the target version vulnerability mapping table contains multiple pieces of data, and all vulnerability identifiers of the target version number are one piece of data in the target version vulnerability mapping table, and one vulnerability identifier corresponds to one type of vulnerability information.

[0009] In a possible implementation manner, the device further includes a target version vulnerability mapping table acquisition unit, wherein the target version vulnerability mapping table acquisition unit is configured to:

[0010] Preprocess the original data of the target system to obtain a first version vulnerability mapping table; wherein, the first version vulnerability mapping table contains multiple original version number intervals and multiple vulnerability identifiers, and one vulnerability identifier is mapped to at least one original version number interval; the original version number interval includes a single version number or multiple consecutive version numbers;

[0011] Summarize the vulnerability identifiers corresponding to each version number in the first version vulnerability mapping table, and construct version number intervals for each version number to obtain the target version vulnerability mapping table.

[0012] In a possible implementation manner, the target version vulnerability mapping table acquisition unit is specifically configured to:

[0013] Ascendingly sort the left and right endpoint version numbers of each original version number interval in the first version vulnerability mapping table to obtain a version number sorting table of the target system;

[0014] Obtain a second version vulnerability mapping table according to the sorting of each version number in the version number sorting table and the vulnerability identifiers corresponding to each version number; wherein, the second version vulnerability mapping table includes multiple version numbers and multiple vulnerability identifiers, and one version number is mapped to at least one vulnerability identifier or not mapped to an identifier;

[0015] Construct a version number interval for any two adjacent version numbers in the second version vulnerability mapping table in sequence to obtain the target version vulnerability mapping table.

[0016] In a possible implementation manner, the target version vulnerability mapping table obtaining unit is specifically configured to:

[0017] For any two adjacent version numbers, perform the following process:

[0018] Determine whether all version numbers in the version number sorting table have been traversed;

[0019] If it is determined that not all version numbers have been traversed, determine whether the vulnerability identifiers corresponding to any two adjacent version numbers are the same;

[0020] If it is determined that the vulnerability identifiers corresponding to any two adjacent version numbers are the same, determine whether the vulnerability identifier corresponding to the next version number adjacent to the first right endpoint version number of the first to-be-merged interval constructed from the any two adjacent version numbers is the same, and determine whether the interval formed by the first right endpoint version number and the next version number adjacent to the first right endpoint version number is a sub-interval of any original version number interval;

[0021] If it is determined that the vulnerability identifiers are different, judge the type of the first to-be-merged interval according to the type of the leading interval.

[0022] In a possible implementation manner, the target version vulnerability mapping table obtaining unit is specifically configured to:

[0023] If the vulnerability identifiers corresponding to the first right endpoint version number and the next version number adjacent to the first right endpoint version number are the same, and the interval formed by the first right endpoint version number and the next version number adjacent to the first right endpoint version number is a sub-interval of any original version number interval, update the first right endpoint version number of the first to-be-merged interval to the next version number adjacent to the first right endpoint version number to obtain a second to-be-merged interval, and determine again whether all version numbers in the version number sorting table have been traversed;

[0024] Otherwise, judge the type of the first to-be-merged interval according to the type of the leading interval.

[0025] In a possible implementation manner, the target version vulnerability mapping table acquisition unit is specifically configured to:

[0026] If it is determined that not all version numbers have been traversed, determine whether the vulnerability identifiers corresponding to the second left and right endpoint version numbers of the second interval to be merged are the same;

[0027] If it is determined that the vulnerability identifiers corresponding to the second left and right endpoint version numbers are the same, determine whether the vulnerability identifiers corresponding to the second right endpoint version number and the next version number adjacent to the second right endpoint version number are the same, and determine whether the interval formed by the second right endpoint version number and the next version number adjacent to the second right endpoint version number is a sub-interval of any original version number interval;

[0028] Otherwise, judge the type of the second interval to be merged according to the type of the leading interval.

[0029] In a possible implementation manner, the target version vulnerability mapping table acquisition unit is specifically configured to:

[0030] If the type of the leading interval is a closed interval, sequentially determine whether the first interval to be merged meets any of the construction conditions of a left-open right-closed interval or an open interval;

[0031] If the type of the leading interval is a left-closed right-open interval, sequentially determine whether the first interval to be merged meets any of the construction conditions of a left-closed right-open-closed interval, a closed interval, or a single version number node;

[0032] If the type of the leading interval is a left-open right-closed interval, sequentially determine whether the first interval to be merged meets any of the construction conditions of a left-open right-closed interval or an open interval;

[0033] If the type of the leading interval is an open interval, sequentially determine whether the first interval to be merged meets any of the construction conditions of a closed interval, a left-closed right-open interval, or a single version number node;

[0034] In a possible implementation manner, the construction conditions of the left-open right-closed interval include determining whether the type of the leading interval is one of a single version number node, a closed interval, or a left-open right-closed interval, whether the first interval to be merged is a sub-interval of any original version number interval, and whether the vulnerability identifiers corresponding to the intersection interval of all original version number intervals containing the first interval to be merged include all the vulnerability identifiers of the first right endpoint version number.

[0035] In a possible implementation, the construction conditions of the open interval include determining whether the type of the leading interval is one of a separate version number node, a closed interval, or a left-open right-closed interval, whether the first interval to be merged is a sub-interval of any original version number interval, and whether the vulnerability identifier corresponding to the first interval to be merged is the vulnerability identifier corresponding to the intersection interval of all original version number intervals containing the first interval to be merged.

[0036] In a possible implementation, the construction conditions of the left-closed right-open interval include determining whether the type of the leading interval is one of an initial starting point, a separate version number node, an open interval, or a left-closed right-open interval, whether the first interval to be merged is a sub-interval of any original version number interval, and whether the vulnerability identifier corresponding to the intersection interval of all original version number intervals containing the first interval to be merged includes all vulnerability identifiers of the first left endpoint version number.

[0037] In a possible implementation, the construction conditions of the closed interval include determining whether the type of the leading interval is one of an initial starting point, an open interval, or a left-closed right-open interval, whether the vulnerability identifiers corresponding to any two adjacent version numbers are the same, whether the first interval to be merged is a sub-interval of any original version number interval, and whether the vulnerability identifier corresponding to the intersection interval of all original version number intervals containing the first interval to be merged includes all vulnerability identifiers of the first left and right endpoint version numbers.

[0038] In a possible implementation, the construction conditions of the separate version number node include determining whether the type of the leading interval is one of an initial starting point, a separate version number node, an open interval, or a left-closed right-open interval, whether the first interval to be merged meets all the conditions in the construction conditions of the closed interval and the left-closed right-open interval, and whether there is a corresponding vulnerability identifier for the separate version number node.

[0039] In a third aspect, the present application provides a computer 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, the steps of the method described in the above aspect are implemented.

[0040] In a fourth aspect, the present application provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and the computer program includes program instructions. When the program instructions are executed by a computer, the computer is caused to execute the method described in any item of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 It is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0042] Figure 2 It is a schematic flowchart of a vulnerability query method provided by an embodiment of the present application;

[0043] Figure 3 It is a schematic flowchart of a process for obtaining a target version vulnerability mapping table of target system C;

[0044] Figure 4 It is a schematic diagram of a "vulnerability - based" vulnerability information query method for financial software B;

[0045] Figure 5 It is another schematic flowchart of a process for obtaining a target version vulnerability mapping table of target system C;

[0046] Figure 6 It is a schematic flowchart of a process for constructing a version number range provided by an embodiment of the present application;

[0047] Figure 7 It is a schematic illustration of version number range merging provided by an embodiment of the present application Figure 1 ;

[0048] Figure 8 It is a schematic illustration of version number range merging provided by an embodiment of the present application Figure 2 ;

[0049] Figure 9 It is another schematic flowchart of a process for constructing a version number range provided by an embodiment of the present application;

[0050] Figure 10 It is a schematic illustration of version number range merging provided by an embodiment of the present application Figure 3 ;

[0051] Figure 11 It is a schematic illustration of version number range merging provided by an embodiment of the present application Figure 4 ;

[0052] Figure 12 It is a schematic illustration of version number range merging provided by an embodiment of the present application Figure 5 ;

[0053] Figure 13 It is a schematic illustration of version number range merging provided by an embodiment of the present application Figure 6 ;

[0054] Figure 14 It is a schematic illustration of version number range merging provided by an embodiment of the present application Figure 7 ;

[0055] Figure 15 It is a schematic illustration of version number range merging provided by an embodiment of the present application Figure 8 ;

[0056] Figure 16Schematic diagram of version number range merging provided by an embodiment of the present application Figure 9 ;

[0057] Figure 17 Schematic diagram of version number range merging provided by an embodiment of the present application Figure 10 ;

[0058] Figure 18 Schematic structural diagram of a vulnerability query device provided by an embodiment of the present application;

[0059] Figure 19 Schematic structural diagram of a computer device provided by an embodiment of the present application. Detailed implementation manners

[0060] To make the objectives, technical solutions, and advantages of the present invention clearer and more understandable, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0061] Currently, in the field of network security, when major network security manufacturers conduct corresponding vulnerability queries and sorting of assets (such as software, systems, etc.), it is a basic security service provided to users. For example, asset vulnerability queries and sorting are performed based on the version information of network assets from public vulnerability information databases (such as CVE) and private vulnerability information databases. And as the requirements for data security and the confidentiality requirements for customer assets become stricter, providing basic version vulnerability queries to users in a privacy query manner based on the vulnerability information databases of security manufacturers themselves will become an increasingly important method in the future network security service field. During the vulnerability privacy query process, users generally do not want the specific vulnerability information they query to be known by service providers, and service providers also do not want users to obtain other vulnerability information other than the vulnerabilities they want to query. Therefore, currently, privacy query technologies such as oblivious transfer and homomorphic encryption are used to implement vulnerability data queries in privacy scenarios. However, although these privacy query technologies can query vulnerability data in a private state, these privacy query technologies are mainly based on vulnerabilities. When querying vulnerability information for a certain version of software assets, it is usually necessary to traverse all the vulnerabilities related to the software assets before determining the vulnerability information associated with the version. Moreover, a single asset vulnerability query request from a user may query and match multiple data records that meet the query conditions in the service provider's database during privacy query, which will have a great impact on data communication and the computing efficiency of the user side and the service side, increase communication overhead, and reduce the query efficiency of vulnerability information.

[0062] To improve the query efficiency of vulnerability information, an embodiment of the present application provides a vulnerability query method. In this method, the vulnerability information query method that "takes vulnerabilities as the main" is converted into a vulnerability information query method that "takes version numbers as the main". Then, when querying vulnerability information, all vulnerability identifiers of the target version number can be directly obtained from the target version vulnerability mapping table according to the target version number of the target system input by the user. Among them, the target version vulnerability mapping table is obtained by summarizing the vulnerability identifiers corresponding to each version number of the target system, avoiding the need to traverse all in the prior art to determine all vulnerability information of a certain version number, greatly reducing the communication overhead, and improving the query efficiency of vulnerability information.

[0063] After introducing the design concept of the embodiment of the present application, the following briefly introduces the application scenarios applicable to the technical solution of the embodiment of the present application. It should be noted that the following introduced application scenarios are only used to illustrate the embodiment of the present application rather than limiting it. In the specific implementation process, the technical solution provided by the embodiment of the present application can be flexibly applied according to actual needs.

[0064] As Figure 1 shown, it is a schematic diagram of an application scenario provided by an embodiment of the present application. This application scenario may include a vulnerability query device 10 and a user terminal 11.

[0065] The vulnerability query device 10 may be a server that provides data storage and data calculation for the vulnerability query process. It may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It may also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms, but is not limited thereto. The vulnerability query device 10 may include one or more processors 101, a memory 102, and an I / O interface 103 for interacting with other devices, etc. In addition, the vulnerability query device 10 may be configured with a database 104, and the database 104 may be used to store corresponding data such as the target version vulnerability mapping table involved in the solution provided by the embodiment of the present application. Among them, the program instructions of the vulnerability query method provided by the embodiment of the present application may be stored in the memory 102 of the vulnerability query device 10, and when these program instructions are executed by the processor 101, they can be used to implement the steps of the vulnerability query method provided by the embodiment of the present application to improve the query efficiency of vulnerability information while reducing the communication overhead.

[0066] The user terminal 11 may be a device that can input the target version number of the target system, such as devices like mobile phones and laptops.

[0067] In a possible implementation, taking the example of user 1 querying all vulnerability information of office system A with version number 2.0.0.0, when the vulnerability query device 10 detects, through the I / O interface 103, the version number 2.0.0.0 of office system A entered by the user on the user terminal 11, the processor 101 of the vulnerability query device 10 will run the program instructions of the vulnerability query method stored in the memory 102. Thus, while reducing communication overhead, the query efficiency of vulnerability information is improved.

[0068] Of course, the method provided by the embodiments of the present application is not limited to Figure 1 the application scenarios shown, and can also be used in other possible application scenarios, which are not restricted by the embodiments of the present application. For Figure 1 the functions that can be achieved by each device in the application scenarios shown will be described together in the subsequent method embodiments, and will not be elaborated here too much. Next, the method of the embodiments of the present application will be introduced with reference to the drawings.

[0069] As Figure 2 shown, it is a schematic flowchart of a vulnerability query method provided by an embodiment of the present application. This method can be executed by the vulnerability query device 10 in Figure 1 . The process of this method is introduced as follows.

[0070] Step 201: According to the target version number of the target system input by the user, obtain all vulnerability identifiers of the target version number from the target version vulnerability mapping table.

[0071] In the embodiments of the present application, the target system has at least one version number. The target version vulnerability mapping table is obtained by summarizing the vulnerability identifiers corresponding to each version number of the target system. And for the convenience of query, in the present application, all vulnerability identifiers corresponding to each version number can be preset as one piece of data. Furthermore, the target version vulnerability mapping table can contain multiple pieces of data, and all vulnerability identifiers of the target version number are one piece of data in the target version vulnerability mapping table. One vulnerability identifier corresponds to one type of vulnerability information.

[0072] In practical applications, the target system can be various software or systems. For example, financial APPs, SMS APPs, camera APPs, and office systems, etc. The vulnerability identifier can be a vulnerability ID. Each target system corresponds to a target version vulnerability mapping table respectively. Of course, multiple different systems can also correspond to the same target version vulnerability mapping table, that is, the target version vulnerability mapping table includes information such as the version numbers and vulnerability identifiers of these different systems.

[0073] Assume that User 2 wants to query vulnerability information for the version number 5.2.4 of financial software B. As shown in Table 1, it is a schematic table of the target version vulnerability mapping table for financial software B. Among them, Null represents "empty", that is, there is no corresponding vulnerability identifier. The target version vulnerability mapping table shown in Table 1 is the target version vulnerability mapping table specifically corresponding to financial software B. Furthermore, User 2 can input the version number 5.2.4 of financial software B on user terminal 11. Then, based on vulnerability query device 10, it can be queried from the target version vulnerability mapping table of financial software B as shown in Table 1 that the version number 5.2.4 is within the version number range [5.2.0, 5.2.4]. Therefore, the vulnerability identifiers corresponding to the version number 5.2.4 are 2, 3, and 4. Furthermore, the user can obtain all the vulnerability information of the version number 5.2.4 according to the vulnerability identifiers 2, 3, and 4.

[0074] Table 1

[0075] Version number range Vulnerability identifier [0,5.2.0) 2,3 [5.2.0,5.2.4] 2,3,4 (5.2.4,5.3.0) 2,3 [5.3.0,5.3.1] 2,3,4 (5.3.1,5.3.3) 2,3 5.3.3 1,2 (5.3.3,5.3.5) 2 5.3.5 Null 5.4 1

[0076] In a possible implementation manner, in the embodiments of the present application, before determining all the vulnerability identifiers of the target version from the target version vulnerability mapping table, it is also necessary to convert the existing vulnerability information query method that "takes vulnerabilities as the main" into a target version vulnerability mapping table of the vulnerability information query method that "takes version numbers as the main". Moreover, for the convenience of the target version vulnerability mapping table, in the embodiments of the present application, it is also possible to first obtain the target version vulnerability mapping table corresponding to each system respectively according to the system as the grouping basis, that is, furthermore, all the version numbers and vulnerability information in the vulnerability information library are converted. Since the process of each system obtaining the target version vulnerability mapping table is the same, therefore, the following takes obtaining the target version vulnerability mapping table of target system C as an example for detailed introduction, as Figure 3 shown, which is a schematic flowchart of obtaining the target version vulnerability mapping table of target system C, and the specific process is introduced as follows.

[0077] Step 301: Preprocess the original data of target system C to obtain the first version vulnerability mapping table.

[0078] In the embodiments of the present application, the first version vulnerability mapping table may include multiple original version number ranges and multiple vulnerability identifiers, and one vulnerability identifier is mapped to at least one original version number range; the original version number range may include a single version number or multiple consecutive version numbers.

[0079] In practical applications, continuing with the above-mentioned financial software B as an example, as Figure 4As shown, it is a schematic diagram of a "vulnerability - based" vulnerability information query method for financial software B. It can be seen that when storing data in the "vulnerability - based" vulnerability information query method, if a user needs to query all vulnerability information of financial software B with a version number of 5.3.1, then it is necessary to traverse all vulnerability identifiers 1, 2, 3, 4 to determine that all vulnerability identifiers for version number 5.3.1 are 2, 3, 4. Furthermore, in the embodiments of the present application, first, the Figure 4 original data of financial software B shown can be subjected to preliminary data extraction. Then, these extracted data of financial software B can be trans - stored in the form of a data frame. As shown in Table 2, it is a schematic table of the first - version vulnerability mapping table of financial software B.

[0080] Table 2

[0081] Software name Version number range Vulnerability identifier Financial Software B 5.3.3 1 Financial Software B 5.4 1 Financial Software B [0,5.3.3) 3 Financial Software B [0,5.3.5) 2 Financial Software B [5.2.0,5.2.4] 4 Financial Software B [5.3.0,5.3.1] 4

[0082] Among them, when trans - storing the extracted data in the data - frame form shown in Table 2, the version numbers are divided in the form of version - number intervals. For example, version numbers between 0 and 5.3.4 all have vulnerability identifier 2. Therefore, in this Table 2, the version - number interval corresponding to vulnerability identifier 2 is [0, 5.3.5). In particular, since the version numbers corresponding to vulnerability identifier 1 are only 5.3.3 and 5.4, and there is no vulnerability identifier 1 for version numbers between 5.3.3 and 5.4, when converting the original data of financial software B into the data - frame form shown in Table 2, version number 5.3.3 and version number 5.4 do not form a version - number interval but are set in different rows respectively. Vulnerability identifier 4 is similar to vulnerability identifier 1. Since there is no vulnerability identifier 4 for version numbers between 5.2.4 and 5.3.4, the version - number interval [5.2.0, 5.2.4] and the version - number interval [5.3.0, 5.3.1] are set in different rows respectively.

[0083] Step 302: Summarize the vulnerability identifiers corresponding to each version number in the first - version vulnerability mapping table, and construct version - number intervals for each version number to obtain the target - version vulnerability mapping table.

[0084] In practical applications, continuing with the above-mentioned financial software B as an example, the vulnerability identifiers corresponding to each version number in the first-version vulnerability mapping table shown in Table 2 can be summarized. For example, all the vulnerability identifiers for version number 0 are 2 and 3, and all the vulnerability identifiers for version number 5.2.0 are 2, 3, 4, etc. After summarizing and generalizing the vulnerability identifiers corresponding to all version numbers, version number intervals are constructed for each version number, that is, the version numbers are still divided in the form of version number intervals, so as to obtain the target-version vulnerability mapping table shown in Table 1. In this target-version vulnerability mapping table, the version numbers within the same version number interval have the same vulnerability identifiers.

[0085] In a possible implementation manner, in the process of obtaining the target-version vulnerability mapping table from the first-version vulnerability mapping table, for the convenience of viewing and statistical summarization, in the embodiments of the present application, the version numbers of the target system can also be sorted in ascending order, and based on the corresponding relationships between these version numbers and each vulnerability identifier, a second-version vulnerability mapping table corresponding to each version number is established, and then based on the second-version vulnerability mapping table, the target-version vulnerability mapping table is obtained. Similarly, since the processes for each system to obtain the second-version vulnerability mapping table are the same, therefore, the following takes the example of obtaining the second-version vulnerability mapping table of the target system C for detailed introduction. As Figure 5 shown, it is another schematic flowchart for obtaining the target-version vulnerability mapping table of the target system C, and the specific process is introduced as follows.

[0086] Step 501: Sort the left and right endpoint version numbers of each original version number interval in the first-version vulnerability mapping table in ascending order to obtain the version number sorting table of the target system.

[0087] In practical applications, continuing with the above-mentioned financial software B as an example, the left and right endpoint version numbers of each original version number interval in the first-version vulnerability mapping table shown in Table 2 can be sorted in ascending order to obtain the version number sorting table of the target system. As shown in Table 3, it is a schematic table of the version number sorting table of the financial software B. Of course, the left and right endpoint version numbers of each original version number interval in the first-version vulnerability mapping table shown in Table 2 can also be sorted in descending order to obtain the version number sorting table of the target system.

[0088] Table 3

[0089] Software name Version number Financial Software B [0,5.2.0,5.2.4,5.3.0,5.3.1,5.3.3,5.3.5,5.4]

[0090] Step 502: Obtain the second-version vulnerability mapping table according to the sorting of each version number in the version number sorting table and the vulnerability identifier corresponding to each version number.

[0091] In the embodiments of the present application, the second version vulnerability mapping table includes multiple version numbers and multiple vulnerability identifiers, and one version number is mapped to at least one vulnerability identifier or not mapped to an identifier. Continuing with the above-mentioned financial software B as an example, as shown in Table 4, it is a schematic table of the second version vulnerability mapping table of financial software B. Among them, each row of the second version vulnerability mapping table has only one version number and the vulnerability identifiers corresponding to the version number.

[0092] Table 4

[0093] Software name Endpoint version number Vulnerability identifier Financial Software B 0 2,3 Financial Software B 5.2.0 2,3,4 Financial Software B 5.2.4 2,3,4 Financial Software B 5.3.0 2,3,4 Financial Software B 5.3.1 2,3,4 Financial Software B 5.3.3 1,2 Financial Software B 5.3.5 Null Financial Software B 5.4 1

[0094] Step 503: Construct version number intervals for any two adjacent version numbers in the second version vulnerability mapping table in sequence to obtain the target version vulnerability mapping table.

[0095] In the embodiments of the present application, since the process of constructing the version number interval for any two adjacent version numbers in the second version vulnerability mapping table is the same, therefore, the following takes the construction of the version number interval between adjacent version numbers 1 and 2 as an example for detailed introduction. As Figure 6 shown, it is a schematic flow diagram of constructing a version number interval provided by the embodiments of the present application, and the specific process is introduced as follows.

[0096] Step 601: Determine whether all version numbers in the version number sorting table have been traversed.

[0097] In the embodiments of the present application, the leading interval indication variable can be defined in advance. As shown in Table 5, it is a schematic table of the leading interval indication variable provided by the embodiments of the present application. Among them, the leading interval refers to the previous merged interval of the interval to be merged, and the leading interval has 6 types: initial starting point, single version number node, closed interval, open interval, left-closed right-open interval, and left-open right-closed interval.

[0098] Table 5

[0099]

[0100] Furthermore, in the embodiments of the present application, at the initial stage of interval merging, parameter initialization can be performed first. Specifically, the leading version number interval indication variable can be initialized to -1, and the left and right endpoint pointers of the interval to be merged can be initialized to 0.

[0101] In practical applications, continuing with the above-mentioned financial software B as an example, for each version number in Table 3, the interval merging judgment can be performed sequentially from left to right, that is, continuously iterate the interval merging process until all version numbers in Table 3 have been traversed, so as to obtain the target version vulnerability mapping table of financial software B as shown in Table 1.

[0102] Step 602: If it is determined that not all version numbers have been traversed, determine whether the vulnerability identifiers corresponding to the adjacent version number 1 and version number 2 are the same.

[0103] Since each version number in the same version number range has the same vulnerability identifier, in the embodiments of the present application, in order to determine whether the adjacent version number 1 and version number 2 can form a version number range, it can be determined whether the adjacent version number 1 and version number 2 can form a version number range by determining whether the vulnerability identifiers corresponding to version number 1 and version number 2 are the same.

[0104] Step 603: If it is determined that the vulnerability identifiers corresponding to the adjacent version number 1 and version number 2 are the same, determine whether the vulnerability identifiers corresponding to the first right endpoint version number of the first merge interval to be obtained by constructing version number 1 and version number 2 and the next version number adjacent to the first right endpoint version number are the same, and determine whether the interval formed by the first right endpoint version number and the next version number adjacent to the first right endpoint version number is a sub-interval of any original version number interval.

[0105] In the embodiments of the present application, in order to facilitate the explanation of the version number range merging process, when determining whether the next adjacent version number 3 of version number 2 can be merged into the first merge interval to be obtained by constructing version number 1 and version number 2, the "pointer" form can be used to process the iterative process of version number range merging. Specifically, the following 4 progressive judgment "right pointer movement" conditions can be used to determine whether version number merging can be performed:

[0106] Condition 1: The vulnerability identifier corresponding to the version number pointed to by the right pointer currently is the same as the vulnerability identifier corresponding to the version number pointed to after the right pointer moves;

[0107] Condition 2: The left-closed right-open interval or closed interval formed by the version number pointed to by the right pointer currently and the version number pointed to after the right pointer moves is a sub-interval of any original version number interval;

[0108] Condition 3: The vulnerability identifiers corresponding to the intersection interval of all original version number intervals containing the first merge interval contain all the vulnerability identifiers on the first merge interval;

[0109] Condition 4: The version number pointed to by the left pointer and the version number pointed to after the right pointer moves also satisfy the above Conditions 1-3.

[0110] In practical applications, when the first interval to be merged obtained by building from version number 1 and version number 2 fully meets the above four conditions, the right pointer can be moved one grid to the right. That is, the first interval to be merged can be successfully built, and it can be further determined whether the next version number can be merged into this first interval to be merged. Of course, if any of the above four conditions is not met, the right pointer cannot be moved. As Figure 7 shown, it is a schematic diagram of version number interval merging provided by an embodiment of the present application Figure 1 . Suppose version number 1 is 5.2.0 and version number 2 is 5.2.4. Then according to Table 4, the vulnerability identifiers of 5.2.0 are <2, 3, 4>, and the vulnerability identifiers of 5.2.4 are also <2, 3, 4>. That is, the vulnerability identifiers corresponding to version number 5.2.0 and version number 5.2.4 are the same. Furthermore, it can be determined whether version number 5.2.0 and version number 5.2.4 meet the above four "right pointer movement" conditions.

[0111] Step 604: If it is determined that the vulnerability identifiers are different, then according to the type of the leading interval, determine the type of the first interval to be merged.

[0112] In practical applications, as Figure 8 shown, it is a schematic diagram of version number interval merging provided by an embodiment of the present application Figure 2 . Suppose that currently in the starting state of version number interval merging, version number 1 is 0 and version number 2 is 5.2.0. Then according to Table 4, the vulnerability identifiers of 0 are <2, 3>, and the vulnerability identifiers of 5.2.0 are also <2, 3, 4>. That is, the vulnerability identifiers corresponding to version number 0 and version number 5.2.0 are different. Furthermore, the type of the first interval to be merged formed by version number 0 and version number 5.2.0 can be further determined according to the type of the leading interval of the first interval to be merged. Specifically, for example, the type of the first interval to be merged can be determined by constructing the following "left-closed right-open interval" conditions:

[0113] Precondition: The type of the leading interval of the first interval to be merged is one of the initial starting point, single version number node, open interval or left-closed right-open interval;

[0114] Condition 1: The first interval to be merged is a sub-interval of any original version number interval;

[0115] Condition 2: The vulnerability identifiers corresponding to the intersection interval of all original version number intervals containing the first interval to be merged contain all the vulnerability identifiers of the first left endpoint version number.

[0116] Continuing with the previous example, assume that version number 1 is 0 and version number 2 is 5.2.0. Since the left and right endpoint version numbers of the leading interval of the first interval to be merged are both 0, that is, the type of the leading interval of this first interval to be merged is the initial starting point. Therefore, version number 0 and version number 5.2.0 satisfy the precondition in the condition for constructing a "left-closed right-open interval". Subsequently, for condition 1 in the condition for constructing a "left-closed right-open interval", since the left-closed right-open interval [0, 5.2.0) formed by version number 0 and version number 5.2.0 is a sub-interval of the original version number interval [0, 5.3.3) and the original version number interval [0, 5.3.5), version number 0 and version number 5.2.0 satisfy condition 1. Furthermore, for condition 2 in the condition for constructing a "left-closed right-open interval", since the original version number interval [0, 5.3.3) and the original version number interval [0, 5.3.5) contain the left-closed right-open interval [0, 5.2.0) formed by version number 0 and 5.2.0, and the intersection interval of the original version number interval [0, 5.3.3) and the original version number interval [0, 5.3.5) is [0, 5.3.3), the vulnerability identifier corresponding to this version number interval [0, 5.3.3) is <2, 3>, and all the vulnerability identifiers of the first left endpoint version number 0 of the left-closed right-open interval [0, 5.2.0) formed by version number 0 and 5.2.0 are also <2, 3>. That is, the vulnerability identifier <2, 3> of the intersection interval [0, 5.3.3) contains all the vulnerability identifiers <2, 3> of the first left endpoint version number 0 of the first interval to be merged. Therefore, version number 0 and version number 5.2.0 also satisfy condition 2. That is to say, version number 0 and 5.2.0 satisfy all the conditions for constructing a "left-closed right-open interval". Therefore, the type of the first interval to be merged formed by version number 0 and 5.2.0 is a left-closed right-open interval, that is, as Figure 7 shown, a new version number interval can be constructed according to version number 0 and 5.2.0: the left-closed right-open interval [0, 5.2.0), and the vulnerability identifier corresponding to this left-closed right-open interval [0, 5.2.0) is <2, 3>. In addition, after constructing the new version number interval, in order to perform iterative processing on each version number in Table 3, it is also necessary to update the indicator variable and the pointer. Specifically, after constructing the new version number interval, move the left pointer indicating version number 0 and the right pointer indicating version number 5.2.0 one position to the right, that is, from the indication situation as Figure 8 shown becomes the indication situation as Figure 7 shown.

[0117] In a possible implementation manner, in the embodiments of the present application, when performing the condition judgment of "right pointer movement", if the vulnerability identifiers corresponding to the first right endpoint version number of the first interval to be merged and the next version number adjacent to the first right endpoint version number are the same, and the interval formed by the first right endpoint version number and the next version number adjacent to the first right endpoint version number is any sub-interval of the original version number interval, that is, when the 4 conditions in the "right pointer movement" condition are satisfied, therefore, the first right endpoint version number of the first interval to be merged can be updated to the next version number adjacent to the first right endpoint version number to obtain the second interval to be merged, and it is determined again whether all version numbers in the version number sorting table have been traversed.

[0118] In practical applications, assume that version number 1 is 5.2.0, version number 2 is 5.2.4, the vulnerability identifier corresponding to the original version number interval [0, 5.3.3) is <3, 4>, and the vulnerability identifier corresponding to the original version number interval [0, 5.3.5) is <2>. Then, the "right pointer movement" condition can be used to make the following judgments on version numbers 5.2.0 and 5.2.4:

[0119] For condition 1, since the version number pointed to by the right pointer is 5.2.4, the vulnerability identifier corresponding to this version number 5.2.4 is <2, 3, 4>, and the version number pointed to after the right pointer moves is 5.3.0, and the vulnerability identifier corresponding to this version number 5.3.0 is also <2, 3, 4>. That is, the vulnerability identifier corresponding to the version number 5.2.4 pointed to by the right pointer is the same as the vulnerability identifier corresponding to the version number 5.3.0 pointed to after the right pointer moves. That is to say, version numbers 5.2.0 and 5.2.4 satisfy condition 1.

[0120] For condition 2, the left-closed right-open interval [5.2.4, 5.3.0) or the closed interval [5.2.4, 5.3.0] formed by version numbers 5.2.4 and 5.3.0 is a sub-interval of the original version number interval [0, 5.3.3) and the original version number interval [0, 5.3.5). Therefore, version numbers 5.2.0 and 5.2.4 satisfy condition 2.

[0121] For condition 3, since the original version number range [0, 5.3.3) and the original version number range [0, 5.3.5) contain the first range to be merged formed by version numbers 5.2.0 and 5.2.4, and the intersection range of the original version number range [0, 5.3.3) and the original version number range [0, 5.3.5) is [0, 5.3.3), the vulnerability identifier corresponding to this version number range [0, 5.3.3) is the union <2, 3, 4> of the vulnerability identifiers corresponding to the original version number range [0, 5.3.3) and the original version number range [0, 5.3.5). This union <2, 3, 4> contains all the vulnerability identifiers <2, 3, 4> on the first range to be merged formed by version numbers 5.2.0 and 5.2.4. Therefore, version numbers 5.2.0 and 5.2.4 satisfy condition 3.

[0122] For condition 4, since the version number pointed to by the left pointer is 5.2.0 and the version number pointed to after the right pointer moves is 5.3.0, therefore, for version numbers 5.2.0 and 5.3.0, it can be further determined that version numbers 5.2.0 and 5.3.0 satisfy conditions 1 - 3 in the "right pointer moves" condition. Therefore, version numbers 5.2.0 and 5.2.4 satisfy condition 4.

[0123] That is to say, version numbers 5.2.0 and 5.2.4 satisfy all the conditions in "right pointer moves". Therefore, the first right endpoint version number 5.2.4 of the first range to be merged can be updated to the next version number 5.3.0 adjacent to the first right endpoint version number 5.2.4 to obtain the second range to be merged formed by version numbers 5.2.0 and 5.3.0. That is, the version number range formed by version numbers 5.2.4 and 5.3.0 is merged with the first range to be merged formed by version numbers 5.2.0 and 5.2.4. In addition, to determine whether all the version numbers in Table 3 have been iterated, after obtaining the second range to be merged formed by version numbers 5.2.0 and 5.3.0, it is also necessary to determine again whether all the version numbers in the version number sorting table shown in Table 3 have been traversed.

[0124] Of course, if version number 1 and version number 2 do not fully satisfy the above 4 "right pointer moves" conditions, then the type of the first range to be merged can be determined according to the type of the leading range of the first range to be merged formed by version number 1 and version number 2.

[0125] Specifically, assume that version number 1 is 5.2.0, version number 2 is 5.2.4, and the vulnerability identifiers corresponding to version numbers 5.2.0 and 5.2.4 are shown in Table 4. Then, it can be known that version numbers 5.2.0 and 5.2.4 meet conditions 1 and 2. Subsequently, for condition 3, since the original version number range [0, 5.3.3) and the original version number range [0, 5.3.5) contain the first range to be merged composed of version numbers 5.2.0 and 5.2.4, and the intersection range of the original version number range [0, 5.3.3) and the original version number range [0, 5.3.5) is [0, 5.3.3), the vulnerability identifier corresponding to this version number range [0, 5.3.3) is the union <2, 3> of the vulnerability identifiers corresponding to the original version number range [0, 5.3.3) and the original version number range [0, 5.3.5). This union <2, 3> does not contain the vulnerability identifier <4> in the vulnerability identifiers <2, 3, 4> corresponding to version numbers 5.2.0 and 5.2.4. Therefore, version numbers 5.2.0 and 5.2.4 do not meet condition 3. Furthermore, since version numbers 5.2.0 and 5.2.4 do not meet condition 3, version numbers 5.2.0 and 5.2.4 do not meet the "right pointer movement" condition. Then, at this time, as described in step 604, the type of the first range to be merged can be determined according to the type of the leading range of the first range to be merged constructed based on version number 1 and version number 2, that is, the type of the first range to be merged can be determined by constructing the "left-closed right-open interval" condition.

[0126] In a possible implementation manner, after obtaining the second range to be merged and determining again whether all version numbers in the version number sorting table have been traversed, in the embodiments of the present application, it is also necessary to further perform range merging judgment on the second range to be merged, as Figure 9 shown, which is another flowchart of constructing a version number range provided by the embodiments of the present application, and the specific process is introduced as follows.

[0127] Step 901: If it is determined that not all version numbers have been traversed, determine whether the vulnerability identifiers corresponding to the second left and right endpoint version numbers of the second range to be merged are the same.

[0128] In practical applications, the specific execution process of this step 901 is similar to that of step 602. Assume that the second range to be merged is constructed by version number 1 and version number 3, that is, the second left and right endpoint version numbers are version number 1 and version number 3 respectively. Therefore, in order to determine whether version number 1 and version number 3 can form a version number range, it can be determined whether version number 1 and version number 3 can form a version number range by determining whether the vulnerability identifiers corresponding to version number 1 and version number 3 are the same.

[0129] Step 902: If it is determined that the vulnerability identifiers corresponding to the second left and right endpoint version numbers are the same, then determine whether the vulnerability identifiers corresponding to the second right endpoint version number and the next version number adjacent to the second right endpoint version number are the same, and determine whether the interval formed by the second right endpoint version number and the next version number adjacent to the second right endpoint version number is a sub-interval of any original version number interval.

[0130] In practical applications, the specific execution process of this step 902 is similar to that of step 603, and it can be judged whether the next version number 4 adjacent to version number 3 can be merged into the second interval to be merged constructed by version number 1 and version number 3 through the "right pointer movement" condition.

[0131] Step 903: Otherwise, judge the type of the second interval to be merged according to the type of the leading interval.

[0132] In practical applications, the specific execution process of this step 903 is similar to that of step 604, and the type of the second interval to be merged can be judged by constructing the "left-closed and right-open interval" condition.

[0133] In a possible implementation manner, in the embodiment of the present application, when judging the type of the first interval to be merged according to the type of the leading interval, the following several methods can be specifically used for judgment:

[0134] The first method: If the type of the leading interval is a closed interval, then sequentially judge whether the first interval to be merged meets any of the construction conditions of the left-open and right-closed interval or the open interval.

[0135] In the embodiment of the present application, if the type of the leading interval is a closed interval, then first it can be judged whether the first interval to be merged meets the following construction conditions of the "left-open and right-closed interval":

[0136] Precondition: The type of the leading interval is one of a single version number node, a closed interval, or a left-open and right-closed interval;

[0137] Condition 1: The first interval to be merged is a sub-interval of any original version number interval;

[0138] Condition 2: The vulnerability identifiers corresponding to the intersection interval of all original version number intervals containing the first interval to be merged contain all the vulnerability identifiers of the first right endpoint version number.

[0139] Furthermore, if the version numbers of the left and right endpoints of the first interval to be merged fully meet the construction conditions of the above-mentioned "left-open and right-closed interval", the type of the first interval to be merged can be determined as a left-open and right-closed interval. For example, assume that the version numbers of the left and right endpoints of the first interval to be merged are 5.3.1 and 5.3.3 respectively. For the precondition, since the leading interval [5.3.0, 5.3.1] of the first interval to be merged constructed by the version numbers 5.3.1 and 5.3.3 is a closed interval, the version numbers 5.3.1 and 5.3.3 meet the precondition in the construction conditions of the "left-open and right-closed interval". Furthermore, for condition 1 in the construction conditions of the "left-open and right-closed interval", since the left-open and right-closed interval (5.3.1, 5.3.3] constructed by the version numbers 5.3.1 and 5.3.3 is a sub-interval of the original version number interval [0, 5.3.5), the version numbers 5.3.1 and 5.3.3 meet condition 1 in the construction conditions of the "left-open and right-closed interval". Further, for condition 2 in the construction conditions of the "left-open and right-closed interval", as shown in Table 2, only the original version number interval [0, 5.3.5) contains the left-open and right-closed interval (5.3.1, 5.3.3]. Therefore, the intersection interval of all the original version number intervals containing the first interval to be merged is [0, 5.3.5). Among them, since the vulnerability identifier corresponding to the version number interval [0, 5.3.5) is <2>, and the vulnerability identifier of the left-open and right-closed interval (5.3.1, 5.3.3] is <1, 2>, that is, the vulnerability identifier corresponding to the version number interval [0, 5.3.5) does not completely contain all the vulnerability identifiers of the left-open and right-closed interval (5.3.1, 5.3.3]. Therefore, the version numbers 5.3.1 and 5.3.3 do not meet condition 2 in the construction conditions of the "left-open and right-closed interval". That is to say, the version numbers 5.3.1 and 5.3.3 do not fully meet the construction conditions of the "left-open and right-closed interval". Therefore, the type of the first interval to be merged constructed by the version numbers 5.3.1 and 5.3.3 cannot be determined as a left-open and right-closed interval.

[0140] Furthermore, when the version numbers of the left and right endpoints of the first interval to be merged do not meet any of the above construction conditions of the "left-open and right-closed interval", it can be further determined whether the first interval to be merged meets the following construction conditions of the "open interval":

[0141] Precondition: The type of the leading interval is one of a single version number node, a closed interval, or a left-open and right-closed interval;

[0142] Condition 1: The first interval to be merged is a sub-interval of any original version number interval;

[0143] Condition 2: The vulnerability identifier corresponding to the first interval to be merged is the vulnerability identifier corresponding to the intersection interval of all the original version number intervals containing any first interval to be merged.

[0144] Continuing with the above example, assuming that the version numbers of the left and right endpoints of the first interval to be merged are 5.3.1 and 5.3.3 respectively, then, according to the foregoing, it can be known that the version numbers 5.3.1 and 5.3.3 also satisfy the preconditions and condition 1 in the construction conditions of the "open interval". Furthermore, for condition 2 in the construction conditions of the "open interval", as shown in Table 2, both the original version number interval [0, 5.3.3) and the original version number interval [0, 5.3.5) contain the open interval (5.3.1, 5.3.3), and the intersection interval of the original version number interval [0, 5.3.3) and the original version number interval [0, 5.3.5) is [0, 5.3.3). The vulnerability identifier of this version number interval [0, 5.3.3) is <2, 3>, and the vulnerability identifier of the open interval (5.3.1, 5.3.3) is also <2, 3>. Subsequently, it can be seen that the vulnerability identifier of the open interval (5.3.1, 5.3.3) is the same as the vulnerability identifier of the intersection interval [0, 5.3.3) of the original version number interval [0, 5.3.3) and the original version number interval [0, 5.3.5). Therefore, the version numbers 5.3.1 and 5.3.3 meet the above-mentioned construction conditions of the "open interval", as Figure 10 shown, which is a schematic diagram of the version number interval merging provided by the embodiment of the present application Figure 3 Based on the version numbers 5.3.1 and 5.3.3, an open interval (5.3.1, 5.3.3) can be constructed, and the vulnerability identifier corresponding to this open interval (5.3.1, 5.3.3) is <2, 3>. At the same time, update the indication variable and the left and right pointers, that is, update the left pointer from pointing to the version number 5.3.1 to pointing to the version number 5.3.3, and update the right pointer from pointing to the version number 5.3.3 to pointing to the version number 5.3.5.

[0145] The second case: If the type of the leading interval is a left-closed right-open interval, then sequentially determine whether the first interval to be merged meets any of the construction conditions of a left-closed right-open closed interval, a closed interval, or a single version number node.

[0146] In the embodiment of the present application, if the type of the leading interval is a left-closed right-open interval, then first, it can be determined whether the version numbers of the left and right endpoints of the first interval to be merged fully meet the foregoing construction conditions of the "left-closed right-open interval". If they meet, it can be determined that the type of the first interval to be merged is a left-closed right-open interval. For example, assuming that the version numbers of the left and right endpoints of the first interval to be merged are 0 and 5.2.0 respectively, then, based on the vulnerability identifiers of the version numbers 0 and 5.2.0 shown in Table 4 and the foregoing construction conditions of the "left-closed right-open interval", it can be known that the version numbers 0 and 5.2.0 meet all the conditions for constructing a "left-closed right-open interval". Therefore, the type of the first interval to be merged formed by the version numbers 0 and 5.2.0 is a left-closed right-open interval.

[0147] Of course, if the first interval to be merged does not meet any of the above construction conditions for the "left-closed and right-open interval", then it can be further determined whether the first interval to be merged meets the following construction conditions for the "closed interval":

[0148] Precondition: The type of the leading interval is one of the initial starting point, open interval, or left-closed and right-open interval;

[0149] Condition 1: The vulnerability identifiers corresponding to any two adjacent version numbers are the same;

[0150] Condition 2: The first interval to be merged is a sub-interval of any original version number interval;

[0151] Condition 3: The vulnerability identifiers corresponding to the intersection interval of all original version number intervals containing the first interval to be merged include all the vulnerability identifiers of the first left and right endpoint version numbers.

[0152] For example, assume that the left and right endpoint version numbers of the first interval to be merged are 5.3.0 and 5.3.1 respectively. Furthermore, based on the vulnerability identifiers of version numbers 5.3.0 and 5.3.1 shown in Table 4 and the aforementioned construction conditions for the "closed interval", it can be known that version numbers 5.3.0 and 5.3.1 meet all the conditions for constructing a "closed interval". Therefore, as Figure 11 shown, it is a schematic diagram of version number interval merging provided by the embodiments of the present application Figure 4 , and the type of the first interval to be merged composed of version numbers 5.3.0 and 5.3.1 is a closed interval.

[0153] Of course, if the first interval to be merged does not meet any of the above construction conditions for the "closed interval", then it can be further determined whether the first interval to be merged meets the following construction conditions for the "single version number node":

[0154] Precondition: The type of the leading interval is one of the initial starting point, single version number node, open interval, or left-closed and right-open interval;

[0155] Condition 1: The first interval to be merged does not meet all the conditions for the construction conditions of the closed interval and the left-closed and right-open interval;

[0156] Condition 2: There is a corresponding vulnerability identifier for the single version number node.

[0157] In the embodiments of the present application, if the left and right endpoint version numbers of the first interval to be merged meet all the conditions for constructing a "single version number node", then the type of the first interval to be merged can be determined as a single version number node.

[0158] The third type: If the type of the leading interval is a left-open and right-closed interval, then successively determine whether the first interval to be merged meets any of the construction conditions for a left-open and right-closed interval or an open interval.

[0159] In the embodiments of the present application, if the type of the leading interval is a left-open and right-closed interval, first, it can be determined whether the version numbers of the left and right endpoints of the first interval to be merged fully meet the construction conditions of the aforementioned "left-open and right-closed interval". If so, it can be determined that the type of the first interval to be merged is a left-open and right-closed interval. Of course, if the first interval to be merged does not meet any of the construction conditions of the above "left-open and right-closed interval", then it can be further determined whether the first interval to be merged meets the construction conditions of the aforementioned "open interval". If so, it can be determined that the type of the first interval to be merged is an open interval.

[0160] The fourth type: If the type of the leading interval is an open interval, then successively determine whether the first interval to be merged meets any of the construction conditions for a closed interval, a left-closed and right-open interval, or a single version number node.

[0161] In the embodiments of the present application, if the type of the leading interval is an open interval, first, it can be determined whether the version numbers of the left and right endpoints of the first interval to be merged fully meet the construction conditions of the aforementioned "closed interval". If so, it can be determined that the type of the first interval to be merged is a closed interval. However, if the first interval to be merged does not meet any of the construction conditions of the above "closed interval", then it can be further determined whether the first interval to be merged meets the construction conditions of the aforementioned "left-closed and right-open interval". If so, it can be determined that the type of the first interval to be merged is a left-closed and right-open interval. Of course, if the first interval to be merged does not meet any of the construction conditions of the above "left-closed and right-open interval", then it can be further determined whether the first interval to be merged meets the construction conditions of the aforementioned "single version number node". If so, it can be determined that the type of the first interval to be merged is a single version number node.

[0162] In a possible implementation manner, in the embodiments of the present application, the version number intervals can be specifically merged and re-divided in the following manner.

[0163] Step1: Perform parameter initialization.

[0164] Specifically, the leading interval, the left endpoint pointer of the first interval to be constructed, and the right endpoint pointer of the interval to be constructed can be initialized. Among them, the indicator variable of the leading interval can be initialized to -1, the left endpoint pointer of the first interval to be constructed can be initialized to 0, and the right endpoint pointer of the first interval to be constructed can be initialized to 0.

[0165] Step 2: For each version number in the version number sorting table, construct version number intervals in sequence from left to right. The pointer movement and version number interval construction rules are as follows:

[0166] Step 2.1: Determine whether the vulnerability identifiers of the version numbers pointed to by the left endpoint pointer (hereinafter referred to as the left pointer) and the right endpoint pointer (hereinafter referred to as the right pointer) of the first interval to be merged are the same;

[0167] Step 2.1.1: If the vulnerability identifiers are different, then sequentially determine whether the version numbers pointed to by the left and right pointers meet the construction conditions of the "left-closed and right-open interval";

[0168] Among them, if the construction conditions of the "left-closed and right-open interval" are met, perform interval construction on the version numbers pointed to by the left and right pointers, and at the same time update the indication variables and the left and right pointers of the leading interval of the interval constructed by the version numbers pointed to by the left and right pointers, and end this loop, return to Step 2.1, and continue iteration; if the construction conditions of the "left-closed and right-open interval" are not met, jump to Step 2.2.

[0169] Step 2.1.2: If the vulnerability identifiers are the same, further determine whether the version numbers pointed to by the left and right pointers meet the right pointer movement conditions;

[0170] Among them, if the right pointer movement conditions are met, move the right pointer. For example, move the right pointer one bit to the right and return to Step 2.1;

[0171] If the right pointer movement conditions are not met, sequentially determine whether the version numbers pointed to by the left and right pointers meet the construction conditions of the closed interval and the left-closed and right-open interval. This judgment process is similar to Step 2.1.1.

[0172] Specifically, if the precondition in the construction condition of the "closed interval" is satisfied, it is possible to further determine whether the version numbers pointed to by the left and right pointers meet the remaining conditions in the construction condition of the "closed interval" (conditions 1-3 in the construction condition of the "closed interval"). If the remaining conditions in the construction condition of the "closed interval" are satisfied, a closed interval can be constructed based on the version numbers pointed to by the left and right pointers. At the same time, update the indicator variable of the leading interval and the left and right pointers, end the current loop, and return to Step2.1 to continue iteration; if the remaining conditions in the construction condition of the "closed interval" are not satisfied, it is possible to further determine whether the version numbers pointed to by the left and right pointers meet the construction condition of the "left-closed right-open interval". If the construction condition of the "left-closed right-open interval" is satisfied, a left-closed right-open interval can be constructed based on the version numbers pointed to by the left and right pointers. At the same time, update the indicator variable of the leading interval and the left and right pointers, end the current loop, return to Step2.1, and continue iteration; if the construction condition of the "left-closed right-open interval" is not satisfied, jump to Step2.2.

[0173] If the precondition in the construction condition of the "closed interval" is not satisfied, jump to Step2.2;

[0174] Step2.2: Determine whether the left and right pointers are adjacent;

[0175] Step2.2.1: If the left and right pointers are not adjacent, move the right pointer back to the left, and then perform the following operations:

[0176] If the type of the leading interval is any one of the initial starting point, left-closed right-open interval, open interval, or in limbo, it is possible to further determine whether the version numbers pointed to by the left and right pointers meet the construction condition of the "closed interval". If the construction condition of the "closed interval" is satisfied, a closed interval can be constructed based on the version numbers pointed to by the left and right pointers. At the same time, update the indicator variable of the leading interval and the left and right pointers, end the current loop, return to Step2.1, and continue iteration; if the construction condition of the "closed interval" is not satisfied, it is possible to further determine whether the version numbers pointed to by the left and right pointers meet the construction condition of the "left-closed right-open interval", and the execution process refers to Step2.1.1;

[0177] If the type of the leading interval is other types (such as left-open right-closed interval or closed interval), it is possible to further determine whether the version numbers pointed to by the left and right pointers meet the construction condition of the "left-open right-closed interval". If the construction condition of the "left-open right-closed interval" is satisfied, a left-open right-closed interval can be constructed based on the version numbers pointed to by the left and right pointers. At the same time, update the indicator variable of the leading interval and the left and right pointers, end the current loop, return to Step2.1, and continue iteration; if the construction condition of the "left-open right-closed interval" is not satisfied, it is possible to go to Step2.2.

[0178] Step2.2.2: If the left and right pointers are adjacent, the type of the leading interval can be determined:

[0179] If the type of the leading interval is any one of the initial starting point, left-closed right-open interval, or open interval, it can be further determined whether the version numbers pointed to by the left and right pointers meet the construction conditions of the "left-closed right-open interval". If the construction conditions of the left-closed right-open interval are met, the left-closed right-open interval can be constructed based on the version numbers pointed to by the left and right pointers. At the same time, update the indicator variables of the leading interval and the left and right pointers, and end this loop, return to Step2.1, and continue the iteration; if the construction conditions of the left-closed right-open interval are not met, a "single version node" can be constructed based on the version numbers pointed to by the left and right pointers. At the same time, update the indicator variable of the leading interval, and end this loop, return to Step2.1, and continue the iteration. Further, if the vulnerability identifier corresponding to the "single version node" is empty, that is, there is no corresponding vulnerability identifier, then this "single version node" is skipped, and at the same time, update the indicator variable of the leading interval, and end this loop, return to Step2.1, and continue the iteration.

[0180] If the type of the leading interval is other types (such as left-open right-closed interval or closed interval), it can be further determined whether the version numbers pointed to by the left and right pointers meet the construction conditions of the "left-open right-closed interval". If the construction conditions of the left-open right-closed interval are met, the left-open right-closed interval can be constructed based on the version numbers pointed to by the left and right pointers. At the same time, update the indicator variables of the leading interval and the left and right pointers, and end this loop, return to Step2.1, and continue the iteration; if the construction conditions of the left-open right-closed interval are not met, it is further determined whether the version numbers pointed to by the left and right pointers meet the construction conditions of the "open interval". If the construction conditions of the open interval are met, the open interval can be constructed based on the version numbers pointed to by the left and right pointers. At the same time, update the indicator variables of the leading interval and the left and right pointers, and end this loop, return to Step2.1, and continue the iteration; if the construction conditions of the open interval are not met, this judgment process is skipped, and at the same time, update the left and right pointers, return to Step2.1, and continue the iteration.

[0181] Further, in the embodiments of the present application, in order to facilitate users to understand the version number interval division and merging of the present application, the following takes the merging of the version numbers in Table 3 from the lower version to the higher version according to the version priority as an example for detailed introduction.

[0182] Assume that the current is in the starting state of merging and judging the version numbers. In this state, both the left pointer and the right pointer point to version 0. First, the right pointer can be moved to obtain, for example, Figure 8The results shown. At this time, the left pointer points to version number 0, and the right pointer points to version number 5.2.0. Furthermore, based on the correspondence between the endpoint version numbers and vulnerability identifiers shown in Table 4, it can be known that version number 0 and version number 5.2.0 correspond to different vulnerability identifiers respectively. Further, execute Step2.1.1 to determine whether the construction condition of the "left-closed right-open interval" is satisfied: the leading interval indication variable of the interval to be merged composed of version number 0 and version number 5.2.0 is the initial value, so the precondition is satisfied; the interval [0, 5.2.0) is a sub-interval of the original version number intervals [0, 5.3.3) and [0, 5.3.5), so condition 1 is satisfied; the intersection interval corresponding to the original version number intervals [0, 5.3.3) and [0, 5.3.5) is [0, 5.3.3), and its corresponding vulnerability identifier is <2, 3>, which includes the vulnerability identifier <2, 3> at the left endpoint. Therefore, a new version number interval [0, 5.2.0) can be constructed, and the vulnerability identifier corresponding to this version number interval is <2, 3>. Further, update the indication variable and the pointer, as Figure 7 shown.

[0183] Further, continue to execute Step2.1 to determine whether the vulnerability identifiers corresponding to version numbers 5.2.0 and 5.2.4 are the same. If they are the same, execute Step2.1.2 to determine whether the "right pointer movement" condition is satisfied: the current right pointer is 5.2.4, and the right pointer after movement is 5.3.0. Their corresponding vulnerability identifiers are both <2, 3, 4>, that is, the vulnerability identifier corresponding to the version pointed to by the right pointer currently is equal to the vulnerability identifier corresponding to the version pointed to by the right pointer after movement. Therefore, condition 1 is satisfied; and the interval [5.2.4, 5.3.0) or [5.2.4, 5.3.0] composed of version numbers 5.2.4 and 5.3.0 is a sub-interval of the original version number intervals [0, 5.3.3) and [0, 5.3.5), so condition 2 is satisfied; however, since the intersection interval of [0, 5.3.3), [0, 5.3.5) and is [0, 5.3.3), and its corresponding vulnerability identifier is the union <2, 3> of the vulnerability identifiers corresponding to the two original version number intervals, which does not include the vulnerability identifier <4> in the vulnerability identifier <2, 3, 4> corresponding to 5.2.4 and 5.3.0, that is, condition 3 is not satisfied; therefore, the interval to be merged composed of version numbers 5.2.0 and 5.2.4 does not satisfy the "right pointer movement" condition.

[0184] Therefore, it is necessary to further determine whether the version numbers 5.2.0 and 5.2.4 meet the construction conditions of the "closed interval": the leading interval of the interval to be merged composed of the version numbers 5.2.0 and 5.2.4 is a left-closed and right-open interval, so it meets the precondition; [5.2.0, 5.2.4] is a sub-interval of the original version number intervals [0, 5.3.3), [0, 5.3.5), and [5.2.0, 5.2.4], so it meets condition 1; the intersection interval of the sub-intervals of the original version number intervals [0, 5.3.3), [0, 5.3.5), and [5.2.0, 5.2.4] is [5.2.0, 5.2.4], and the vulnerability identifier corresponding to this [5.2.0, 5.2.4] is the union <2, 3, 4> of the vulnerability identifiers corresponding to the three original version number intervals, which includes the vulnerabilities in the vulnerability identifiers <2, 3, 4> corresponding to the version numbers 5.2.4 and 5.3.0, so it meets condition 2; furthermore, it can be determined that the version numbers 5.2.0 and 5.2.4 meet the construction conditions of the "closed interval", so a new version number interval [5.2.0, 5.2.4] can be constructed, and its corresponding vulnerability identifier is <2, 3, 4>; further, the indicator variable and pointer are updated, as Figure 12 shown, which is a schematic diagram of the version number interval merging provided by the embodiments of the present application Figure 5 .

[0185] Furthermore, continue to execute Step2.1. At this time, the left and right pointers point to the version numbers 5.2.4 and 5.3.0 respectively. Since the vulnerability identifiers of the version numbers 5.2.4 and 5.3.0 are equal, Step2.1.2 can be executed to determine whether the "right pointer movement" condition is met: the right pointer currently points to the version number 5.3.0 and points to the version number 5.3.1 after moving. Since the vulnerability identifiers corresponding to the version numbers 5.3.0 and 5.3.1 are equal, condition 1 is met; since the closed interval [5.3.0, 5.3.1] formed by the currently pointed 5.3.0 of the right pointer and the pointed 5.3.1 after moving is a sub-interval of the original version number intervals [0, 5.3.3), [0, 5.3.5), and [5.3.0, 5.3.1], condition 2 is met; the intersection of the original version number intervals [0, 5.3.3), [0, 5.3.5), and [5.3.0, 5.3.1] is [5.3.0, 5.3.1], and the vulnerability identifier corresponding to this [5.3.0, 5.3.1] is <2, 3, 4>, meeting condition 3; however, since the interval formed by the version number 5.2.4 pointed to by the left pointer and the version number 5.3.1 pointed to by the right pointer after moving meets condition 1 and condition 2 of the above "right pointer movement" condition, but does not meet condition 3; therefore, the version numbers 5.2.4 and 5.3.0 do not meet the "right pointer movement" condition.

[0186] Furthermore, it is necessary to further determine whether the version numbers 5.2.4 and 5.3.0 meet the construction conditions of a "closed interval": Since the leading interval of the interval to be merged formed by the version numbers 5.2.4 and 5.3.0 is a closed interval, therefore, it does not meet the precondition in the construction conditions of a "closed interval". Furthermore, it is necessary to further determine whether the version numbers 5.2.4 and 5.3.0 meet the construction conditions of a "left-closed and right-open interval". Obviously, it also does not meet the precondition in the construction conditions of a "left-closed and right-open interval".

[0187] Therefore, jump to Step2.2; First, determine whether the left and right pointers are adjacent. If the left and right pointers are adjacent, then it is possible to enter the judgment in Step2.2.2; Since the leading interval [5.2.0, 5.3.4] of the interval to be merged formed by the version numbers 5.2.4 and 5.3.0 is a closed interval, therefore, it is possible to perform the judgment on the construction conditions of a "left-open and right-closed interval": Since the leading interval of the interval to be merged formed by the version numbers 5.2.4 and 5.3.0 is a closed interval, therefore, it meets the precondition of a "left-open and right-closed interval"; (5.2.4, 5.3.0] is a sub-interval of the original version number intervals [0, 5.3.3) and [0, 5.3.5), therefore, it meets Condition 1; The intersection interval of the original version number intervals is [5.3.3, 5.3.5), and the vulnerability identifier corresponding to this [5.3.3, 5.3.5) is <2, 3>, which does not contain the vulnerability identifier <4> in the vulnerability identifier <2, 3, 4> corresponding to the version number 5.3.0. Therefore, the version numbers 5.2.4 and 5.3.0 do not meet Condition 2; That is to say, the version numbers 5.2.4 and 5.3.0 do not meet the construction conditions of a "left-open and right-closed interval".

[0188] Further, it is necessary to perform the judgment on the construction conditions of an "open interval" for the version numbers 5.2.4 and 5.3.0: Since the leading interval of the interval to be merged formed by the version numbers 5.2.4 and 5.3.0 is a closed interval, and the current pointer fails to construct a left-open and right-closed interval, therefore, it meets the leading condition in the construction conditions of an "open interval"; The open interval (5.2.4, 5.3.0) is a sub-interval of [0, 5.3.3) and [0, 5.3.5), therefore, it meets Condition 1 in the construction conditions of an "open interval"; Therefore, perform the construction of an open interval for the version numbers 5.2.4 and 5.3.0, and the vulnerability identifier corresponding to this open interval is <2, 3>; Further, update the indicator variable and the pointer, as Figure 13 shown, which is a schematic diagram of the version number interval merging provided by the embodiment of the present application Figure 6 .

[0189] Further, continue to execute Step 2.1. Determine whether the vulnerability identifiers corresponding to version numbers 5.3.0 and 5.3.1 are the same. If they are the same, then execute Step 2.1.2 to determine whether the "right pointer movement" condition is met: The right pointer currently points to version number 5.3.1 and after movement, it points to version number 5.3.3. Their vulnerability identifiers are <2, 3, 4> and <1, 2> respectively, and it does not meet Condition 1 in the "right pointer movement" condition. Therefore, do not move the right pointer.

[0190] Further, first determine whether version numbers 5.3.0 and 5.3.1 meet the "closed interval" construction condition: Since the leading interval of the interval to be merged constructed by version numbers 5.3.0 and 5.3.1 is an open interval, therefore, it meets the precondition in the "closed interval" construction condition; The version numbers pointed to by the left and right pointers are 5.3.0 and 5.3.1 respectively, and their vulnerability identifiers are equal. Therefore, it meets Condition 1 in the "closed interval" construction condition; The constructed closed interval [5.3.0, 5.3.1] is a sub-interval of the original version number intervals [0, 5.3.3), [0, 5.3.5), and [5.3.0, 5.3.1]. Therefore, it meets Condition 2 in the "closed interval" construction condition; The intersection interval of the original version number intervals [0, 5.3.3), [0, 5.3.5), and [5.3.0, 5.3.1] is [5.3.0, 5.3.1], and the vulnerability identifier corresponding to this [5.3.0, 5.3.1] is <2, 3, 4>, which includes the vulnerability identifier <2, 3, 4> corresponding to the closed interval [5.3.0, 5.3.1]. Therefore, it meets Condition 3 in the "closed interval" construction condition; That is to say, therefore, version numbers 5.3.0 and 5.3.1 meet the "closed interval" construction condition. Therefore, the closed interval [5.3.0, 5.3.1] can be constructed, and the indicator variable and pointer can be updated, as Figure 11 shown.

[0191] Further, continue to execute Step 2.1. Determine whether the vulnerability identifiers corresponding to version numbers 5.3.1 and 5.3.3 are the same. Since their corresponding vulnerability identifiers are <2, 3, 4> and <1, 2> respectively, that is, the vulnerability identifiers are not the same. Therefore, Step 2.1.1 can be executed to further determine whether version numbers 5.3.1 and 5.3.3 meet the "left-closed and right-open interval" construction condition: Since the precondition of the interval to be merged formed by version numbers 5.3.1 and 5.3.3 is a closed interval, it does not meet the precondition in the "left-closed and right-open interval" construction condition.

[0192] Therefore, jump to Step 2.2 to perform pointer adjacency judgment to determine whether the left and right pointers are adjacent. Since the current left and right pointers are adjacent, Step 2.2.2 can be executed to further perform type judgment on the pre-interval: Since the pre-interval of the mergeable interval formed by version numbers 5.3.1 and 5.3.3 is a closed interval and it does not belong to the initial starting point or a left-closed right-open interval; therefore, further, it is necessary to determine whether version numbers 5.3.1 and 5.3.3 meet the construction conditions of a "left-open right-closed interval": Since the pre-interval of the mergeable interval formed by version numbers 5.3.1 and 5.3.3 is a closed interval, therefore, it meets the precondition in the construction conditions of a "left-open right-closed interval"; (5.3.1, 5.3.3] is a sub-interval of the original version number interval [0, 5.3.5), so it meets condition 1 in the construction conditions of a "left-open right-closed interval"; Since the vulnerability identifier corresponding to the original version number interval [0, 5.3.5) is <2> and it cannot contain the vulnerability identifier <1, 2> corresponding to version number 5.3.3, therefore, it does not meet condition 2 in the construction conditions of a "left-open right-closed interval", that is to say, version numbers 5.3.1 and 5.3.3 do not meet the construction conditions of a "left-open right-closed interval".

[0193] Therefore, further, it is necessary to determine whether version numbers 5.3.1 and 5.3.3 meet the construction conditions of an "open interval": Since the pre-interval of the mergeable interval formed by version numbers 5.3.1 and 5.3.3 is a closed interval and the construction of the left-open right-closed interval fails, therefore, it meets the precondition in the construction conditions of an "open interval"; (5.3.1, 5.3.3) is a sub-interval of the original version number intervals [0, 5.3.3) and [0, 5.3.5), meeting condition 1 in the construction conditions of an "open interval"; Furthermore, perform additional construction operations to determine that the vulnerability identifier corresponding to the open interval (5.3.1, 5.3.3) is the vulnerability identifier <2, 3> corresponding to the intersection interval [0, 5.3.3) of the original version number intervals [0, 5.3.3) and [0, 5.3.5); Therefore, the open interval (5.3.1, 5.3.3) can be constructed, and its corresponding vulnerability identifier is <2, 3>. At the same time, update the indicator variable and the left and right pointers, as Figure 10 shown.

[0194] Furthermore, continue to execute Step 2.1 to determine whether the vulnerability identifiers corresponding to version numbers 5.3.3 and 5.3.5 are the same. Since their corresponding vulnerability identifiers are <1, 2> and <null>, that is, the vulnerability identifiers are different. Therefore, Step2.1.1 can be executed to further determine whether the version numbers 5.3.3 and 5.3.5 meet the construction conditions of the "left-closed and right-open interval": Since the pre-interval of the interval to be merged constructed by the version numbers 5.3.3 and 5.3.5 is an open interval, the precondition in the construction conditions of the "left-closed and right-open interval" is met; the interval [5.3.3, 5.3.5) is a sub-interval of the original version number interval [0, 5.3.5), so the condition 1 in the construction conditions of the "left-closed and right-open interval" is met; the vulnerability identifier corresponding to the original version number interval [0, 5.3.5) is <2>, and it does not contain the vulnerability identifier <1, 2> of version 5.3.3, so the condition 2 in the construction conditions of the "left-closed and right-open interval" is not met; that is, the construction conditions of the "left-closed and right-open interval" are not met.

[0195] Further, jump to Step2.2 to determine whether the left and right pointers are adjacent. Since the current left and right pointers are adjacent, Step2.2.2 can be executed to further determine the type of the pre-interval: Since the pre-interval of the interval to be merged constructed by the version numbers 5.3.3 and 5.3.5 is an open interval, it is again determined whether the version numbers 5.3.3 and 5.3.5 meet the construction conditions of the "left-closed and right-open interval". Obviously, the version numbers 5.3.3 and 5.3.5 do not meet the construction conditions of the "left-closed and right-open interval". Therefore, a "single version number node" can be further constructed, that is, a single version number node is constructed for the version number 5.3.3 pointed to by the left pointer, and the vulnerability identifier corresponding to this single version number node is <1, 2>. Update the indication variable and do not update the pointer, as Figure 14 shown, which is a schematic diagram of the version number interval merging provided by the embodiment of the present application Figure 7 .

[0196] Further, continue to execute Step2.1. Since the left and right pointers do not move, but only the pre-interval indication variable changes, it is continued to determine whether the version numbers 5.3.3 and 5.3.5 meet the construction conditions of the "left-closed and right-open interval": Since the pre-interval of the interval to be merged constructed by the version numbers 5.3.3 and 5.3.5 is a single version number node, the precondition in the construction conditions of the "left-closed and right-open interval" is not met.

[0197] Then, jump to Step 2.2 to determine whether the left and right pointers are adjacent. Since the current left and right pointers are adjacent, Step 2.2.2 can be executed to further determine the type of the pre-interval: Since the pre-interval of the interval to be merged constructed by version numbers 5.3.3 and 5.3.5 is a single version number node, therefore, it is necessary to further determine the construction conditions of the "left-open and right-closed interval": Since the pre-interval of the interval to be merged constructed by version numbers 5.3.3 and 5.3.5 is a single version number node, therefore, the precondition in the construction conditions of the "left-open and right-closed interval" is satisfied; (5.3.3, 5.3.5] is not a sub-interval of any original version number interval, so the condition 1 in the construction conditions of the "left-open and right-closed interval" is not satisfied. That is to say, version numbers 5.3.3 and 5.3.5 do not satisfy the construction conditions of the "left-open and right-closed interval".

[0198] Furthermore, it is necessary to determine the construction conditions of the "open interval" for version numbers 5.3.3 and 5.3.5: Since the pre-interval of the interval to be merged constructed by version numbers 5.3.3 and 5.3.5 is a single version number node, and the construction of the "left-open and right-closed interval" fails, therefore, the precondition in the construction conditions of the "open interval" is satisfied; (5.3.3, 5.3.5) is a sub-interval of the original version number interval [0, 5.3.5), so the condition 1 in the construction conditions of the "open interval" is satisfied. In addition, since the vulnerability identifier corresponding to the original version number interval [0, 5.3.5) is <2>, the vulnerability identifier corresponding to (5.3.3, 5.3.5) is <2>; that is to say, version numbers 5.3.3 and 5.3.5 satisfy the construction conditions of the "open interval", so the open interval (5.3.3, 5.3.5) can be constructed, and the indicator variable and the left and right pointers are updated, as Figure 15 shown, which is a schematic diagram of the version number interval merging provided by the embodiment of the present application Figure 8 .

[0199] Furthermore, continue to execute Step 2.1 to determine whether the vulnerability identifiers corresponding to version numbers 5.3.5 and 5.4 are the same. Since their corresponding vulnerability identifiers are respectively <null>and <1>, that is, the vulnerability identifiers are different. Therefore, Step 2.1.1 can be executed to further determine whether the version numbers 5.3.5 and 5.4 meet the construction conditions of the "left-closed and right-open interval": Since the leading interval of the interval to be merged constructed by the version numbers 5.3.5 and 5.4 is an open interval, therefore, it meets the leading condition in the construction conditions of the "left-closed and right-open interval"; the interval [5.3.5, 5.4) is a sub-interval that does not belong to any original version number interval, so it does not meet condition 1 in the construction conditions of the "left-closed and right-open interval". That is to say, it does not meet the construction conditions of the "left-closed and right-open interval".

[0200] Furthermore, jump to Step 2.2 to determine whether the left and right pointers are adjacent. Since the current left and right pointers are adjacent, Step 2.2.2 can be executed to further determine the type of the leading interval: Since the leading interval of the interval to be merged constructed by the version numbers 5.3.5 and 5.4 is an open interval, it is necessary to determine again whether the version numbers 5.3.5 and 5.4 meet the construction conditions of the "left-closed and right-open interval". Obviously, the version numbers 5.3.5 and 5.4 do not meet the construction conditions of the "left-closed and right-open interval". Therefore, the construction of the "single version number node" can be further carried out. Since the leading interval of the interval to be merged constructed by the version numbers 5.3.5 and 5.4 is an open interval, it meets the leading condition in the construction conditions of the "single version number node"; however, since the vulnerability identifier corresponding to the 5.3.5 version corresponding to the left pointer is empty, it does not meet the construction conditions of the "single version number node". Furthermore, the construction of the version number node 5.3.5 can be directly skipped, the indicator variable can be updated, and the left and right pointers are not updated.

[0201] Furthermore, judge the "left-open and right-closed interval" for the version numbers 5.3.5 and 5.4: Since the leading interval of the interval to be merged constructed by the version numbers 5.3.5 and 5.4 is a single version node, it meets the leading condition in the construction conditions of the "left-open and right-closed interval"; (5.3.5, 5.4] is a sub-interval that does not belong to any original version number interval, so it does not meet condition 1 in the construction conditions of the "left-open and right-closed interval". That is to say, the version numbers 5.3.5 and 5.4 do not meet the construction conditions of the "left-open and right-closed interval".

[0202] Further, perform a "half-open interval" construction condition judgment on version numbers 5.3.5 and 5.4: Since the leading interval of the interval to be merged constructed by version numbers 5.3.5 and 5.4 is a single version node, therefore, the leading condition in the "half-open interval" construction condition is satisfied; (5.3.5, 5.4] does not belong to the sub-interval of any original version number interval, so the condition 1 in the "half-open interval" construction condition is not satisfied; that is to say, version numbers 5.3.5 and 5.4 do not satisfy the "half-open interval" construction condition. Therefore, this interval is skipped, and the indicator variable and the left and right pointers are directly updated, as Figure 16 shown, which is a schematic diagram of version number interval merging provided by the embodiment of the present application Figure 9 , where the empty vulnerability identifier corresponding to version 5.3.5 is retained for convenience of explanation. In the actual implementation of the algorithm, it can also be decided whether to retain the single version number node with an empty vulnerability identifier according to needs.

[0203] At this time, both the left and right pointers point to the end, and the traversal of the ordered list of version number endpoints is completed. Therefore, enter Step3 for result correction; Step3: Correct the end endpoint:

[0204] Step3.1: If the leading interval is not a right-closed interval (i.e., left-closed right-open, half-open interval, or interval skipped), create a single version node or skip the node for the end endpoint;

[0205] Step3.2: Otherwise, end the process and go to Step4;

[0206] Step4: Output the newly synthesized version number interval and the vulnerability identifier on the original vulnerability data corresponding to this interval;

[0207] Correct the result. Since the leading interval is in a skipped state and is not a right-closed interval at this time, enter the processing flow of Step3.1, create a single version node for version 5.4 at the end of the list, and end the process to output the final result, as Figure 17 shown, which is a schematic diagram of version number interval merging provided by the embodiment of the present application Figure 10 . As shown in the example data, after re-merging and dividing the version number intervals of the original software asset version vulnerability data, the only one version corresponds to at most one data information. Compared with the situation where the original data may correspond to multiple data, the re-divided data is more conducive to improving the efficiency of vulnerability data query in the privacy query scenario.

[0208] In summary, in the embodiments of the present application, the vulnerability information query method dominated by "vulnerabilities" is converted into a vulnerability information query method dominated by "version numbers". Furthermore, when querying vulnerability information, all vulnerability identifiers of the target version number can be directly obtained from the target version vulnerability mapping table according to the target version number of the target system input by the user. The target version vulnerability mapping table is obtained by summarizing the vulnerability identifiers corresponding to each version number of the target system, avoiding the need to traverse all in the prior art to determine all vulnerability information of a certain version number, greatly reducing the communication overhead, and improving the query efficiency of vulnerability information.

[0209] As Figure 18 shown, based on the same inventive concept, the embodiments of the present application provide a vulnerability query device, and the device 180 includes:

[0210] A vulnerability identifier acquisition unit 1801, configured to obtain all vulnerability identifiers of the target version number from the target version vulnerability mapping table according to the target version number of the target system input by the user; wherein, the target system has at least one version number, the target version vulnerability mapping table is obtained by summarizing the vulnerability identifiers corresponding to each version number of the target system, and the target version vulnerability mapping table contains multiple pieces of data, and all vulnerability identifiers of the target version number are one piece of data in the target version vulnerability mapping table, and one vulnerability identifier corresponds to one type of vulnerability information.

[0211] In a possible implementation manner, the device further includes a target version vulnerability mapping table acquisition unit 1802, wherein the target version vulnerability mapping table acquisition unit 1802 is configured to:

[0212] Preprocess the original data of the target system to obtain a first version vulnerability mapping table; wherein, the first version vulnerability mapping table contains multiple original version number intervals and multiple vulnerability identifiers, and one vulnerability identifier is mapped to at least one original version number interval; the original version number interval contains a single version number or multiple consecutive version numbers;

[0213] Summarize the vulnerability identifiers corresponding to each version number in the first version vulnerability mapping table, and construct version number intervals for each version number to obtain the target version vulnerability mapping table.

[0214] In a possible implementation manner, the target version vulnerability mapping table acquisition unit 1802 is specifically configured to:

[0215] Ascendingly sort the left and right endpoint version numbers of each original version number interval in the first version vulnerability mapping table to obtain a version number sorting table of the target system;

[0216] Obtain a second version vulnerability mapping table according to the sorting of each version number in the version number sorting table and the vulnerability identifiers corresponding to each version number; wherein, the second version vulnerability mapping table includes multiple version numbers and multiple vulnerability identifiers, and one version number is mapped to at least one vulnerability identifier or not mapped to an identifier.

[0217] Construct version number intervals for any two adjacent version numbers in the second version vulnerability mapping table in sequence to obtain a target version vulnerability mapping table.

[0218] In a possible implementation manner, the target version vulnerability mapping table obtaining unit 1802 is specifically configured to:

[0219] For any two adjacent version numbers, perform the following process:

[0220] Determine whether all version numbers in the version number sorting table have been traversed;

[0221] If it is determined that not all version numbers have been traversed, determine whether the vulnerability identifiers corresponding to any two adjacent version numbers are the same;

[0222] If it is determined that the vulnerability identifiers corresponding to any two adjacent version numbers are the same, determine whether the vulnerability identifier corresponding to the next version number adjacent to the first right endpoint version number of the first interval to be merged obtained by constructing from any two adjacent version numbers is the same, and determine whether the interval formed by the first right endpoint version number and the next version number adjacent to the first right endpoint version number is a sub-interval of any original version number interval;

[0223] If it is determined that the vulnerability identifiers are not the same, judge the type of the first interval to be merged according to the type of the leading interval.

[0224] In a possible implementation manner, the target version vulnerability mapping table obtaining unit 1802 is specifically configured to:

[0225] If the vulnerability identifiers corresponding to the first right endpoint version number and the next version number adjacent to the first right endpoint version number are the same, and the interval formed by the first right endpoint version number and the next version number adjacent to the first right endpoint version number is a sub-interval of any original version number interval, update the first right endpoint version number of the first interval to be merged to the next version number adjacent to the first right endpoint version number to obtain a second interval to be merged, and determine again whether all version numbers in the version number sorting table have been traversed;

[0226] Otherwise, judge the type of the first interval to be merged according to the type of the leading interval.

[0227] In a possible implementation manner, the target version vulnerability mapping table obtaining unit 1802 is specifically configured to:

[0228] If it is determined that not all version numbers have been traversed, determine whether the vulnerability identifiers corresponding to the second left and right endpoint version numbers of the second interval to be merged are the same respectively;

[0229] If it is determined that the vulnerability identifiers corresponding to the second left and right endpoint version numbers are the same respectively, determine whether the vulnerability identifiers corresponding to the second right endpoint version number and the next version number adjacent to the second right endpoint version number are the same, and determine whether the interval formed by the second right endpoint version number and the next version number adjacent to the second right endpoint version number is a sub-interval of any original version number interval;

[0230] Otherwise, judge the type of the second interval to be merged according to the type of the leading interval.

[0231] In a possible implementation manner, the target version vulnerability mapping table obtaining unit 1802 is specifically configured to:

[0232] If the type of the leading interval is a closed interval, sequentially determine whether the first interval to be merged meets any of the construction conditions of a left-open right-closed interval or an open interval;

[0233] If the type of the leading interval is a left-closed right-open interval, sequentially determine whether the first interval to be merged meets any of the construction conditions of a left-closed right-open-closed interval, a closed interval or a single version number node;

[0234] If the type of the leading interval is a left-open right-closed interval, sequentially determine whether the first interval to be merged meets any of the construction conditions of a left-open right-closed interval or an open interval;

[0235] If the type of the leading interval is an open interval, sequentially determine whether the first interval to be merged meets any of the construction conditions of a closed interval, a left-closed right-open interval or a single version number node;

[0236] In a possible implementation manner, the construction conditions of a left-open right-closed interval include determining whether the type of the leading interval is one of a single version number node, a closed interval or a left-open right-closed interval, whether the first interval to be merged is a sub-interval of any original version number interval, and whether the vulnerability identifier corresponding to the intersection interval of all original version number intervals containing the first interval to be merged includes all vulnerability identifiers of the first right endpoint version number.

[0237] In a possible implementation manner, the construction conditions of an open interval include determining whether the type of the leading interval is one of a single version number node, a closed interval or a left-open right-closed interval, whether the first interval to be merged is a sub-interval of any original version number interval, and whether the vulnerability identifier corresponding to the first interval to be merged is the vulnerability identifier corresponding to the intersection interval of all original version number intervals containing any first interval to be merged.

[0238] In a possible implementation, the construction conditions for a left-closed and right-open interval include determining whether the type of the leading interval is one of an initial starting point, a separate version number node, an open interval, or a left-closed and right-open interval, whether the first interval to be merged is a sub-interval of any original version number interval, and whether the vulnerability identifier corresponding to the intersection interval of all the original version number intervals containing the first interval to be merged includes all the vulnerability identifiers of the first left endpoint version number.

[0239] In a possible implementation, the construction conditions for a closed interval include determining whether the type of the leading interval is one of an initial starting point, an open interval, or a left-closed and right-open interval, whether the vulnerability identifiers corresponding to any two adjacent version numbers are the same, whether the first interval to be merged is a sub-interval of any original version number interval, and whether the vulnerability identifier corresponding to the intersection interval of all the original version number intervals containing the first interval to be merged includes all the vulnerability identifiers of the first left and right endpoint version numbers.

[0240] In a possible implementation, the construction conditions for a separate version number node include determining whether the type of the leading interval is one of an initial starting point, a separate version number node, an open interval, or a left-closed and right-open interval, whether the first interval to be merged meets all the conditions in the construction conditions for a closed interval and a left-closed and right-open interval, and whether there is a corresponding vulnerability identifier for the separate version number node.

[0241] The device can be used to execute Figures 2 to 17 the method described in the embodiments shown, and therefore, for the functions that can be achieved by each functional unit of the device, reference can be made to Figures 2 to 17 the description of the embodiments shown, which will not be elaborated here. Among them, the functional units represented by the dashed lines are non-essential functional units.

[0242] Please refer to Figure 19 , based on the same technical concept, an embodiment of the present application also provides a computer device 190, which may include a memory 1901 and a processor 1902.

[0243] The memory 1901 is used to store a computer program executed by the processor 1902. The memory 1901 may mainly include a program storage area and a data storage area. Among them, the program storage area may store an operating system, application programs required for at least one function, etc.; the data storage area may store data created according to the use of the computer device, etc. The processor 1902 may be a central processing unit (CPU), or a digital processing unit, etc. In the embodiments of the present application, the specific connection medium between the above-mentioned memory 1901 and the processor 1902 is not limited. The embodiments of the present application are in Figure 19 In the middle, a memory 1901 and a processor 1902 are connected through a bus 1903. The bus 1903 is shown in Figure 19 thick lines in the middle. The connection manners between other components are only for illustrative purposes and are not restrictive. The bus 1903 can be divided into an address bus, a data bus, a control bus, etc. For the sake of easy representation, Figure 19 only one thick line is used to represent it in the middle, but it does not mean that there is only one bus or one type of bus.

[0244] The memory 1901 can be a volatile memory, such as a random-access memory (RAM); the memory 1901 can also be a non-volatile memory, such as a read-only memory, a flash memory, a hard disk drive (HDD), or a solid-state drive (SSD), or the memory 1901 is any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 1901 can be a combination of the above memories.

[0245] The processor 1902 is used to execute the method performed by the device in the embodiment as Figures 2 to 17 shown when calling the computer program stored in the memory 1901.

[0246] Based on the same inventive concept, an embodiment of the present application provides a computer-readable storage medium. The computer-readable storage medium stores a computer program. The computer program includes program instructions. When the program instructions are executed by a computer, the computer is made to execute the vulnerability query method as discussed above. Since the principle and method for the above computer-readable storage medium to solve problems are similar, the implementation of the above computer-readable storage medium can refer to the implementation of the method, and the repeated parts will not be described again.

[0247] Those of ordinary skill in the art will understand that all or part of the steps to implement the above method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps including those of the above method embodiments. The aforementioned storage medium includes various media that can store program codes, such as removable storage devices, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs. Alternatively, if the above integrated units of the present invention are implemented in the form of software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the embodiments of the present invention, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media that can store program codes, such as removable storage devices, ROM, RAM, magnetic disks, or optical discs.

[0248] Although the preferred embodiments of the present application have been described, those skilled in the art can make additional changes and modifications to these embodiments once they learn the basic creative concept. Therefore, the appended claims are intended to be construed as including the preferred embodiments and all changes and modifications that fall within the scope of the present application.

[0249] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application also intends to include these changes and modifications.< / null> < / null>

Claims

1. A vulnerability query method, characterized in that, The method includes: According to the target version number of the target system input by the user, all vulnerability identifiers of the target version number are obtained from the target version vulnerability mapping table; wherein, the target system has at least one version number, the target version vulnerability mapping table is obtained by summarizing the vulnerability identifiers corresponding to each version number of the target system, and the target version vulnerability mapping table contains multiple pieces of data. All vulnerability identifiers of the target version number are one piece of data in the target version vulnerability mapping table, and one vulnerability identifier corresponds to one type of vulnerability information; Wherein, before obtaining all vulnerability identifiers of the target version number from the target version vulnerability mapping table according to the target version number of the target system input by the user, the method includes: Preprocessing the original data of the target system to obtain a first version vulnerability mapping table; wherein, the first version vulnerability mapping table contains multiple original version number intervals and multiple vulnerability identifiers, and one vulnerability identifier is mapped to at least one original version number interval; the original version number interval contains a single version number or multiple consecutive version numbers; Ascendingly sorting the left and right endpoint version numbers of each original version number interval in the first version vulnerability mapping table to obtain a version number sorting table of the target system; According to the sorting of each version number in the version number sorting table and the vulnerability identifiers corresponding to each version number respectively, a second version vulnerability mapping table is obtained; wherein, the second version vulnerability mapping table includes multiple version numbers and multiple vulnerability identifiers, and one version number is mapped to at least one vulnerability identifier or not mapped to an identifier; Successively constructing version number intervals for any two adjacent version numbers in the second version vulnerability mapping table to obtain the target version vulnerability mapping table.

2. The method according to claim 1, wherein, The successive construction of version number intervals for any two adjacent version numbers in the second version vulnerability mapping table includes: For any two adjacent version numbers, the following process is executed: Determine whether all version numbers in the version number sorting table have been traversed; If it is determined that not all version numbers have been traversed, determine whether the vulnerability identifiers corresponding to the any two adjacent version numbers are the same; If it is determined that the vulnerability identifiers corresponding to the any two adjacent version numbers are the same, determine whether the vulnerability identifiers corresponding to the first right endpoint version number of the first to-be-merged interval constructed by the any two adjacent version numbers and the next version number adjacent to the first right endpoint version number are the same, and determine whether the interval formed by the first right endpoint version number and the next version number adjacent to the first right endpoint version number is a sub-interval of any original version number interval; If it is determined that the vulnerability identifiers are different, judge the type of the first to-be-merged interval according to the type of the leading interval.

3. The method according to claim 2, wherein After determining whether the vulnerability identifiers corresponding to the first right endpoint version number of the first interval to be merged and the next version number adjacent to the first right endpoint version number are the same, and determining whether the interval formed by the first right endpoint version number and the next version number adjacent to the first right endpoint version number is a sub-interval of any original version number interval, the method includes: If the vulnerability identifiers corresponding to the first right endpoint version number of the first interval to be merged and the next version number adjacent to the first right endpoint version number are the same, and the interval formed by the first right endpoint version number and the next version number adjacent to the first right endpoint version number is a sub-interval of any original version number interval, update the first right endpoint version number of the first interval to be merged to the next version number adjacent to the first right endpoint version number to obtain a second interval to be merged, and determine again whether all version numbers in the version number sorting table have been traversed; Otherwise, judge the type of the first interval to be merged according to the type of the leading interval.

4. The method according to claim 3, wherein After obtaining the second interval to be merged and determining again whether all version numbers in the version number sorting table have been traversed, the method includes: If it is determined that not all version numbers have been traversed, determine whether the vulnerability identifiers corresponding to the second left and right endpoint version numbers of the second interval to be merged are the same; If it is determined that the vulnerability identifiers corresponding to the second left and right endpoint version numbers are the same, determine whether the vulnerability identifiers corresponding to the second right endpoint version number and the next version number adjacent to the second right endpoint version number are the same, and determine whether the interval formed by the second right endpoint version number and the next version number adjacent to the second right endpoint version number is a sub-interval of any original version number interval; Otherwise, judge the type of the second interval to be merged according to the type of the leading interval.

5. The method according to any one of claims 2-3, characterized in that, Judging the type of the first interval to be merged according to the type of the leading interval includes: If the type of the leading interval is a closed interval, sequentially judge whether the first interval to be merged meets any of the construction conditions of a left-open right-closed interval or an open interval; If the type of the leading interval is a left-closed right-open interval, sequentially judge whether the first interval to be merged meets any of the construction conditions of a left-closed right-open-closed interval, a closed interval, or a single version number node; If the type of the leading interval is a left-open right-closed interval, sequentially judge whether the first interval to be merged meets any of the construction conditions of a left-open right-closed interval or an open interval; If the type of the leading interval is an open interval, sequentially judge whether the first interval to be merged meets any of the construction conditions of a closed interval, a left-closed right-open interval, or a single version number node.

6. The method according to claim 5, characterized in that, The construction conditions of the left-open right-closed interval include judging whether the type of the leading interval is one of a single version number node, a closed interval, or a left-open right-closed interval, whether the first interval to be merged is a sub-interval of any original version number interval, and whether the vulnerability identifier corresponding to the intersection interval of all original version number intervals containing the first interval to be merged contains all vulnerability identifiers of the first right endpoint version number.

7. The method according to claim 5, characterized in that The construction conditions of the open interval include determining whether the type of the leading interval is one of a single version number node, a closed interval, or a left-open right-closed interval, whether the first interval to be merged is a sub-interval of any original version number interval, and whether the vulnerability identifier corresponding to the first interval to be merged is the vulnerability identifier corresponding to the intersection interval of all the original version number intervals containing the first interval to be merged.

8. The method according to claim 5, characterized in that, The construction conditions of the left-closed right-open interval include determining whether the type of the leading interval is one of an initial starting point, a single version number node, an open interval, or a left-closed right-open interval, whether the first interval to be merged is a sub-interval of any original version number interval, and whether the vulnerability identifier corresponding to the intersection interval of all the original version number intervals containing the first interval to be merged includes all the vulnerability identifiers of the first left endpoint version number.

9. The method according to claim 5, characterized in that, The construction conditions of the closed interval include determining whether the type of the leading interval is one of an initial starting point, an open interval, or a left-closed right-open interval, whether the vulnerability identifiers corresponding to any two adjacent version numbers are the same, whether the first interval to be merged is a sub-interval of any original version number interval, and whether the vulnerability identifier corresponding to the intersection interval of all the original version number intervals containing the first interval to be merged includes all the vulnerability identifiers of the first left and right endpoint version numbers.

10. The method according to claim 5, wherein The construction conditions of the single version number node include determining whether the type of the leading interval is one of an initial starting point, a single version number node, an open interval, or a left-closed right-open interval, whether the first interval to be merged meets all the conditions in the construction conditions of the closed interval and the left-closed right-open interval, and whether there is a corresponding vulnerability identifier for the single version number node.

11. A vulnerability query device, characterized in that, The device includes: A vulnerability identifier acquisition unit, configured to acquire all the vulnerability identifiers of the target version number from a target version vulnerability mapping table according to the target version number of the target system input by the user; wherein, the target system has at least one version number, the target version vulnerability mapping table is obtained by summarizing the vulnerability identifiers corresponding to the respective version numbers of the target system, and the target version vulnerability mapping table contains multiple pieces of data, all the vulnerability identifiers of the target version number are one piece of data in the target version vulnerability mapping table, and one vulnerability identifier corresponds to one type of vulnerability information; Wherein, the device further includes a target version vulnerability mapping table acquisition unit, and the target version vulnerability mapping table acquisition unit is configured to: Preprocess the original data of the target system to obtain a first version vulnerability mapping table; wherein, the first version vulnerability mapping table contains multiple original version number intervals and multiple vulnerability identifiers, and one vulnerability identifier is mapped to at least one original version number interval; the original version number interval includes a single version number or multiple consecutive version numbers; Ascendingly sort the left and right endpoint version numbers of each original version number interval in the first version vulnerability mapping table to obtain a version number sorting table of the target system; Obtain a second version vulnerability mapping table according to the sorting of each version number in the version number sorting table and the vulnerability identifiers corresponding to each version number; wherein, the second version vulnerability mapping table includes multiple version numbers and multiple vulnerability identifiers, and one version number is mapped to at least one vulnerability identifier or not mapped to an identifier. Construct version number intervals for any two adjacent version numbers in the second version vulnerability mapping table in sequence to obtain the target version vulnerability mapping table.

12. A computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that When the processor executes the computer program, it implements the steps of the method according to any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, and the computer program includes program instructions. When the program instructions are executed by a computer, the computer is caused to execute the method according to any one of claims 1-10.

Citation Information

Patent Citations

  • Scanning prompt method and device for software vulnerabilities

    CN103473505A

  • Vulnerability detection method and device based on oval

    CN111859399A

  • Unauthorized database vulnerability scanning method and system, storage medium and equipment

    CN112395618A

  • Security vulnerability defense method and device

    CN112702300A