Host vulnerability life cycle management method, system, storage medium and computer device thereof

Abstract

The application is suitable for the technical field of computer vulnerability management, and provides a host vulnerability life cycle management method, which comprises the following steps: marking a security vulnerability detected by a system as a to-be-repaired vulnerability; setting a to-be-repaired vulnerability which exceeds a predetermined time threshold and is not repaired as a timeout unrepaired vulnerability; detecting whether the timeout unrepaired vulnerability has been repaired, and if yes, ending the life cycle of the security vulnerability; otherwise, re-marking the timeout unrepaired vulnerability as the to-be-repaired vulnerability. The application also provides a host vulnerability life cycle management system, a storage medium for storing a computer program for executing the method, and a computer device for implementing the method. Therefore, the application solves the problem that security operation personnel do not focus on security vulnerabilities, repeatedly verify and operate, and saves the cost of internal security operation of an enterprise.

Description

Technical Field

[0001] This invention relates to the field of computer vulnerability management technology, and in particular to a host vulnerability lifecycle management method, system, storage medium and computer equipment thereof. Background Technology

[0002] Enterprises have complex internal assets and are discovering more and more host security vulnerabilities. Traditional spreadsheets are no longer sufficient to manage the lifecycle of vulnerabilities, so enterprises are gradually shifting to managing them through programs on host management systems. However, ordinary program management relies solely on manual follow-up by security operations, which is not only time-consuming and labor-intensive but also inefficient and lacks focus.

[0003] In summary, the existing methods have many problems in practical use, so it is necessary to improve them. Summary of the Invention

[0004] To address the aforementioned shortcomings, the present invention aims to provide a host vulnerability lifecycle management method, system, storage medium, and computer equipment, enabling security personnel to focus on vulnerabilities that have not been patched after a timeout, vulnerabilities that have been confirmed to be patched without repeated verification, and vulnerabilities that can be processed in batches. This solves the problems of security operations personnel not focusing on security vulnerabilities, repeatedly verifying and repeatedly following up on them, and saves the cost of internal security operations for enterprises.

[0005] To achieve the above objectives, this invention provides a host vulnerability lifecycle management method, comprising the following steps:

[0006] Mark the security vulnerabilities detected by the system as vulnerabilities to be patched;

[0007] The vulnerability to be repaired that has not been repaired after exceeding a predetermined time threshold is set as an unrepaired vulnerability that has timed out.

[0008] Check whether the timed-out unpatched vulnerability has been patched. If so, end the lifecycle of the corresponding security vulnerability; otherwise, remark the timed-out unpatched vulnerability as the vulnerability to be patched.

[0009] The step of setting the vulnerability to be repaired that has exceeded a predetermined time threshold as a timeout unrepaired vulnerability includes:

[0010] The system tracks the pending status of the marked vulnerabilities.

[0011] Check whether the system timer for the corresponding vulnerability to be fixed exceeds the predetermined time threshold. If so, change the vulnerability to be fixed to the timeout unfixed vulnerability.

[0012] The host vulnerability lifecycle management method also includes:

[0013] Check whether the vulnerability to be patched has been patched; if so, end the lifecycle of the corresponding security vulnerability.

[0014] According to the host vulnerability lifecycle management method, the step of detecting whether the timed-out unpatched vulnerability has been patched, and if so, ending the lifecycle of the corresponding security vulnerability; otherwise, remarking the timed-out unpatched vulnerability as a vulnerability to be patched includes:

[0015] The system verifies or manually verifies whether the timed-out unpatched vulnerability is in a pending state. If so, the timed-out unpatched vulnerability is remarked as a pending vulnerability; otherwise, the security vulnerability is output as patched, and the lifecycle of the corresponding security vulnerability ends.

[0016] A host vulnerability lifecycle management system was also proposed, including:

[0017] The marking unit is used to mark security vulnerabilities detected by the system as vulnerabilities that need to be fixed.

[0018] A conversion unit is used to set the vulnerability to be repaired that has not been repaired after a predetermined time threshold as an unrepaired timeout vulnerability.

[0019] The first detection unit is used to detect whether the timed-out unpatched vulnerability has been patched. If so, the lifecycle of the corresponding security vulnerability is ended; otherwise, the timed-out unpatched vulnerability is remarked as the vulnerability to be patched.

[0020] The conversion unit is specifically used for:

[0021] The system tracks the pending status of the marked vulnerabilities.

[0022] Check whether the system timer for the corresponding vulnerability to be fixed exceeds the predetermined time threshold. If so, change the vulnerability to be fixed to the timeout unfixed vulnerability.

[0023] It also includes:

[0024] The second detection unit is used to detect whether the vulnerability to be repaired has been repaired, and if so, to end the life cycle of the corresponding security vulnerability.

[0025] The first detection unit is used for:

[0026] The system verifies or manually verifies whether the timed-out unpatched vulnerability is in a pending state. If so, the timed-out unpatched vulnerability is remarked as a pending vulnerability; otherwise, the security vulnerability is output as patched, and the lifecycle of the corresponding security vulnerability ends.

[0027] Additionally, a storage medium and a computer device are provided, the storage medium being used to store a computer program for executing the aforementioned host vulnerability lifecycle management method.

[0028] The computer device includes a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor. When the processor executes the computer program, it implements the aforementioned host vulnerability lifecycle management method.

[0029] The host vulnerability lifecycle management method, system, storage medium, and computer equipment described in this invention enable security personnel to focus on vulnerabilities that have not been patched after a timeout, vulnerabilities that have been confirmed to be patched without repeated verification, and vulnerabilities that can be processed in batches. This solves the problems of security operations personnel not focusing on security vulnerabilities, repeatedly verifying and repeatedly following up on them, and saves the cost of internal security operations for enterprises. Attached Figure Description

[0030] Figure 1 This is a flowchart illustrating the steps of the host vulnerability lifecycle management method used in a preferred embodiment of the present invention.

[0031] Figure 2 This is a structural block diagram of the host vulnerability lifecycle management system according to a preferred embodiment of the present invention;

[0032] Figure 3 This is a flowchart illustrating the processing status of the host vulnerability lifecycle management system according to a preferred embodiment of the present invention. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0034] It should be noted that references to "an embodiment," "embodiment," "example embodiment," etc., in this specification refer to the described embodiment including specific features, structures, or characteristics, but not every embodiment must include these specific features, structures, or characteristics. Furthermore, such expressions do not refer to the same embodiment. Moreover, when describing specific features, structures, or characteristics in conjunction with embodiments, whether or not explicitly described, it is indicated that incorporating such features, structures, or characteristics into other embodiments is within the knowledge of those skilled in the art.

[0035] Furthermore, certain terms are used in the specification and subsequent claims to refer to specific components or parts. Those skilled in the art will understand that manufacturers may use different names or terms to refer to the same component or part. This specification and subsequent claims do not distinguish components or parts by differences in name, but rather by differences in function. The terms "comprising" and "including" used throughout the specification and subsequent claims are open-ended and should be interpreted as "including but not limited to." Additionally, the term "connection" here includes any direct and indirect electrical connection means. Indirect electrical connection means include connections made through other means.

[0036] Figure 1 A preferred embodiment of the present invention provides a host vulnerability lifecycle management method, comprising the following steps:

[0037] S101: Mark the security vulnerabilities detected by the system as vulnerabilities to be patched.

[0038] Specifically, each security vulnerability detected by the system is marked as a vulnerability to be repaired, either automatically or manually.

[0039] Specifically, step S101 involves detecting the generation of the security vulnerability and automatically marking the generated security vulnerability as a vulnerability to be repaired.

[0040] S102: Set the vulnerability to be repaired that has not been repaired after exceeding the predetermined time threshold as a timeout unrepaired vulnerability.

[0041] Step S102 further includes:

[0042] The system tracks the pending status of the marked vulnerabilities.

[0043] Check whether the system timer for the corresponding vulnerability to be fixed exceeds the predetermined time threshold. If so, change the vulnerability to be fixed to an unfixed vulnerability that has timed out.

[0044] If a vulnerability to be repaired is not automatically repaired by the system or manually repaired after a predetermined time threshold, the vulnerability to be repaired will be changed to an unrepaired vulnerability that has exceeded the time limit.

[0045] S103: Detect whether the timed-out unpatched vulnerability has been patched. If so, end the lifecycle of the corresponding security vulnerability; otherwise, re-mark the timed-out unpatched vulnerability as the vulnerability to be patched.

[0046] Specifically, the system can be set to periodically detect unpatched vulnerabilities that have timed out, and determine whether the vulnerabilities have been automatically patched by the system or manually selected for patching. If the vulnerabilities have been patched, the lifecycle of the corresponding security vulnerabilities ends; otherwise, the vulnerabilities are remarked as new vulnerabilities to be patched, so as to return to the initial state when the security vulnerabilities were first detected and perform detection, thereby playing a role in cyclical detection and monitoring.

[0047] Step S103 includes: system verification or manual verification of whether the timed-out unpatched vulnerability is still in a pending state. If so, the timed-out unpatched vulnerability is remarked as a pending vulnerability; otherwise, the vulnerability is output as patched, and the lifecycle of the corresponding vulnerability ends. The system can periodically verify whether the timed-out unpatched vulnerability is still in a pending state. If so, the vulnerability is remarked as a pending vulnerability for cyclical monitoring and management; otherwise, it is determined that the timed-out unpatched vulnerability has been automatically patched by the system or manually selected for patching, thus ending the vulnerability's lifecycle. Alternatively, administrators can actively verify whether the timed-out unpatched vulnerability is still in a pending state. If so, they can choose to patch the vulnerability or ignore it; ignored vulnerabilities will also end their lifecycle. Otherwise, it is determined that the timed-out unpatched vulnerability has been patched.

[0048] Preferably, step S103 specifically includes: the system periodically and automatically verifies the pending status of the timed-out unpatched vulnerability; if the system verifies that the timed-out unpatched vulnerability is still in the pending status, it checks whether the number of times the timed-out unpatched vulnerability has been verified exceeds a preset verification number threshold; if so, the timed-out unpatched vulnerability is re-marked as a pending vulnerability. That is, it is preferable to set a verification number threshold for the timed-out unpatched vulnerability, which can be one, two, three, or more times. By setting a periodic verification mechanism for the timed-out unpatched vulnerability, its repair status is automatically verified after a certain period. If it has been repaired, its lifecycle ends; otherwise, it is verified again after a certain period, until the number of verifications reaches the predetermined verification number threshold. Then, the timed-out unpatched vulnerability is re-marked as a pending vulnerability, and the re-marked pending vulnerability will be processed again in a loop, improving the efficiency of security vulnerability processing.

[0049] Alternatively, in other embodiments, step S103 may specifically include: the system periodically and automatically verifying the pending status of the timed-out unrepaired vulnerability; if the system verifies that the timed-out unrepaired vulnerability is still in the pending status, then it checks whether the verification time of the timed-out unrepaired vulnerability exceeds a preset verification time threshold; if so, the timed-out unrepaired vulnerability is re-marked as a pending vulnerability. This embodiment sets a verification time threshold for the timed-out unrepaired vulnerability, which can be a time period of one hour, two hours, or three hours, etc. Once marked as a timed-out unrepaired vulnerability, timing begins, and within this verification time threshold, the system periodically and automatically verifies the pending status of the timed-out unrepaired vulnerability. If the verification time threshold is exceeded and the timed-out unrepaired vulnerability is still in the pending status, then the timed-out unrepaired vulnerability is re-marked as a pending vulnerability, and the loop processing resumes. The timed-out unrepaired vulnerability can be verified multiple times periodically within the predetermined verification time threshold, thereby improving the vulnerability handling capability.

[0050] Preferably, the method further includes the step of: detecting whether the vulnerability to be repaired has been repaired, and if so, ending the lifecycle of the corresponding security vulnerability.

[0051] Vulnerabilities detected by the system are in a pending state and may be automatically fixed by the system. Therefore, it is necessary to check in a timely manner whether the vulnerabilities have been fixed and remove security vulnerabilities that do not meet the conditions, that is, to filter out the fixed vulnerabilities.

[0052] More preferably, other embodiments also include the step of: system detection or manual detection to determine whether the vulnerability to be patched is a vulnerability that does not require processing; if so, the corresponding vulnerability to be patched is marked as ignored, and the lifecycle of the corresponding security vulnerability is ended. Specifically, the vulnerability that does not require processing can be marked as ignored in a single instance or in batches, and the lifecycle of the corresponding security vulnerability can be ended.

[0053] Figure 2 The preferred embodiment of the host vulnerability lifecycle management system 100 of the present invention is shown, comprising a marking unit 10, a conversion unit 20, and a first detection unit 30; the marking unit 10, the conversion unit 20, and the first detection unit 30 are interconnected; wherein:

[0054] The marking unit 10 is used to mark security vulnerabilities detected by the system as vulnerabilities to be repaired; the conversion unit 20 is used to set the vulnerabilities to be repaired that have exceeded a predetermined time threshold as timeout vulnerabilities; the first detection unit 30 is used to detect whether the timeout vulnerabilities have been repaired. If so, the lifecycle of the corresponding security vulnerability is ended; otherwise, the timeout vulnerabilities are remarked as vulnerabilities to be repaired. The specific functions of the marking unit 10, conversion unit 20, and first detection unit 30 can be implemented by computer hardware and software, thereby adding automatic triggering of timeout judgment, automatic verification and repair functions, and batch processing functions to the basic manual operation and maintenance vulnerability lifecycle management. This solves the problem of security operations personnel not focusing on security vulnerabilities, repeatedly verifying, and repeatedly operating and following up, saving the cost of internal security operations for enterprises.

[0055] In this preferred embodiment, the marking unit 10 is specifically used for:

[0056] The system detects the generation of the security vulnerability and automatically marks the generated security vulnerability as a vulnerability to be fixed.

[0057] The conversion unit 20 is specifically used for:

[0058] The system tracks the pending status of the marked vulnerabilities.

[0059] The system checks whether the system timer for the corresponding vulnerability to be patched exceeds the predetermined time threshold. If so, the vulnerability to be patched is changed to the timed-out unpatched vulnerability. The system timer starts immediately upon the vulnerability being patched being marked, and further processing is performed based on the change in the vulnerability's attributes according to the time elapsed during the system timer.

[0060] The first detection unit 30 is specifically used for:

[0061] The system verifies or manually verifies whether the timed-out unpatched vulnerability is in a pending state. If so, the timed-out unpatched vulnerability is remarked as a pending vulnerability; otherwise, the system outputs that the security vulnerability has been patched and the lifecycle of the corresponding security vulnerability ends.

[0062] Even better, this embodiment also includes a second detection unit 40, which is used to detect whether the vulnerability to be repaired has been repaired, and if so, to end the life cycle of the corresponding security vulnerability.

[0063] In other embodiments, the first detection unit 30 is used for system verification or manual verification of whether the timed-out unpatched vulnerability is in a pending state. If so, the timed-out unpatched vulnerability is re-marked as a pending vulnerability; otherwise, the security vulnerability is output as patched, and the lifecycle of the corresponding security vulnerability ends. Preferably, a verification threshold is set for the timed-out unpatched vulnerability, which can be one, two, three, or more times. By setting a timed verification mechanism for the timed-out unpatched vulnerability, its patching status is automatically verified after a certain period. If it has been patched, its lifecycle ends; otherwise, another verification is performed after a certain period, until the number of verifications reaches the predetermined verification threshold. Then, the timed-out unpatched vulnerability is re-marked as a pending vulnerability, and the loop processing is restarted, improving the processing efficiency of security vulnerabilities.

[0064] Alternatively, in other embodiments, the first detection unit 30 may be used to automatically verify the pending status of the timed-out unrepaired vulnerability at regular intervals. If the system verifies that the timed-out unrepaired vulnerability is still in the pending status, it checks whether the verification time of the timed-out unrepaired vulnerability exceeds a preset verification time threshold. If so, the timed-out unrepaired vulnerability is re-marked as a pending vulnerability. This embodiment sets a verification time threshold for the timed-out unrepaired vulnerability. The verification time threshold can be a time period such as one hour, two hours, or three hours. Once marked as a timed-out unrepaired vulnerability, timing begins, and within the verification time threshold, the system automatically verifies the pending status of the timed-out unrepaired vulnerability at regular intervals. If the verification time threshold is exceeded and the timed-out unrepaired vulnerability is still in the pending status, the timed-out unrepaired vulnerability is re-marked as a pending vulnerability, and the loop processing resumes. The timed-out unrepaired vulnerability can be verified multiple times at regular intervals within the predetermined verification time threshold, thereby improving the vulnerability handling capability.

[0065] In another embodiment, a vulnerability ignoring unit is further included, the vulnerability ignoring unit being used for:

[0066] The system or manual inspection determines whether the vulnerability to be fixed is one that does not require handling. If so, the corresponding vulnerability to be fixed is marked as ignored, and the lifecycle of the corresponding security vulnerability is terminated.

[0067] Furthermore, the vulnerability ignoring unit is specifically used for:

[0068] The vulnerability to be patched that does not require processing can be marked as ignored in a single instance or in batches, and the lifecycle of the corresponding security vulnerability can be ended.

[0069] See Figure 3 The processing flow in this embodiment is as follows:

[0070] When the system detects a vulnerability, it marks the vulnerability as pending (i.e., pending vulnerability). When the pending vulnerability exceeds the timeout period set by the system, the pending vulnerability will automatically change its status to the timeout unrepaired status (timeout unrepaired vulnerability).

[0071] Vulnerabilities in the pending or unpatched state can either be manually verified or automatically retrieved for verification by the system.

[0072] Vulnerabilities under verification will be checked by the system or manually to determine if they have been fixed. If the system verifies that the vulnerability has been fixed, it will be marked as automatically confirmed fixed; if the system verifies that the vulnerability has not been fixed, it will be rolled back to a pending status. If manual verification confirms that the vulnerability has been fixed, it will be marked as fixed; if manual verification confirms that the vulnerability has not been fixed, it will be rolled back to a pending status.

[0073] Vulnerabilities that are pending or have timed out and do not require patching should be manually marked as ignored if no action is needed.

[0074] Vulnerabilities that have been confirmed or ignored and are in the automatic repair phase are considered to have reached the end of their lifecycle. At this point, the entire lifecycle of a vulnerability can be fully controlled, ensuring that no vulnerability issues on the host are overlooked.

[0075] The present invention also provides a storage medium for storing, for example, Figure 1 The computer program of the host vulnerability lifecycle management method, for example, is a computer program instruction. When executed by a computer, it can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. The program instructions invoking the methods of this application may be stored in a fixed or removable storage medium, and / or transmitted via data streams in broadcast or other signal carrying media, and / or stored in the storage medium of a computer device operating according to the program instructions. Here, one embodiment according to this application includes, as... Figure 2 The computer device of the host vulnerability lifecycle management system shown preferably includes a storage medium for storing computer programs and a processor for executing computer programs, wherein when the computer program is executed by the processor, the computer device is triggered to execute the methods and / or technical solutions based on the foregoing embodiments.

[0076] It should be noted that this application can be implemented in software and / or a combination of software and hardware, for example, using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In one embodiment, the software program of this application can be executed by a processor to implement the steps or functions described above. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. Furthermore, some steps or functions of this application can be implemented in hardware, for example, as circuitry that works with a processor to perform the various steps or functions.

[0077] The method according to the invention can be implemented on a computer as a computer-implemented method, or in dedicated hardware, or a combination of both. Executable code or portions thereof for the method according to the invention can be stored on a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Preferably, the computer program product includes non-transitory program code components stored on a computer-readable medium so as to execute the method according to the invention when the program product is executed on a computer.

[0078] In a preferred embodiment, the computer program includes computer program code components adapted to perform all the steps of the method according to the invention when the computer program is run on a computer. Preferably, the computer program is embodied on a computer-readable medium.

[0079] In summary, the host vulnerability lifecycle management method, system, storage medium, and computer equipment described in this invention enable security personnel to focus on vulnerabilities that have not been patched after a timeout, eliminate the need for repeated verification of vulnerabilities that have already been patched, and process vulnerabilities in batches. This solves the problems of security operations personnel not focusing on security vulnerabilities, repeatedly verifying and repeatedly following up on them, and saves the cost of internal security operations for enterprises.

[0080] Of course, the present invention may have other various embodiments. Without departing from the spirit and essence of the present invention, those skilled in the art can make various corresponding changes and modifications according to the present invention, but these corresponding changes and modifications should all fall within the protection scope of the appended claims.

Claims

1. A method for host vulnerability lifecycle management, the method comprising: The method comprises the steps of: marking a security vulnerability detected by a system as a to-be-fixed vulnerability; setting the to-be-fixed vulnerability that is not fixed beyond a predetermined time threshold as a timeout un-fixed vulnerability; detecting whether the timeout un-fixed vulnerability has been fixed, and if so, ending the life cycle of the security vulnerability; otherwise, re-marking the timeout un-fixed vulnerability as the to-be-fixed vulnerability; detecting whether the timeout un-fixed vulnerability has been fixed, and if so, ending the life cycle of the security vulnerability; otherwise, re-marking the timeout un-fixed vulnerability as the to-be-fixed vulnerability further comprises the steps of: the system automatically verifies the to-be-fixed state of the timeout un-fixed vulnerability, and if the system verifies that the timeout un-fixed vulnerability is still in the to-be-fixed state, detecting whether the number of verifications of the timeout un-fixed vulnerability exceeds a preset verification number threshold; or detecting whether the verification time of the timeout un-fixed vulnerability exceeds a preset verification time threshold; if so, re-marking the timeout un-fixed vulnerability as the to-be-fixed vulnerability; the step of setting the to-be-fixed vulnerability that is not fixed beyond a predetermined time threshold as a timeout un-fixed vulnerability comprises the steps of: system timing the to-be-fixed state of the marked to-be-fixed vulnerability; detecting whether the system timing of the corresponding to-be-fixed vulnerability exceeds the predetermined time threshold, and if so, changing the to-be-fixed vulnerability to the timeout un-fixed vulnerability. 2.The host vulnerability lifecycle management method of claim 1, wherein, Further comprising the steps of: detecting whether the to-be-fixed vulnerability has been fixed, and if so, ending the life cycle of the security vulnerability. 3.The host vulnerability lifecycle management method of claim 1, wherein, The step of detecting whether the timeout un-fixed vulnerability has been fixed, and if so, ending the life cycle of the security vulnerability; otherwise, re-marking the timeout un-fixed vulnerability as the to-be-fixed vulnerability further comprises the steps of: manually verifying whether the timeout un-fixed vulnerability is in the to-be-fixed state, and if so, re-marking the timeout un-fixed vulnerability as the to-be-fixed vulnerability, otherwise, outputting that the security vulnerability has been fixed, and ending the life cycle of the security vulnerability. 4.The host vulnerability lifecycle management method of claim 1, wherein, Further comprising the steps of: the system or manual detection of whether the to-be-fixed vulnerability is a non-handling vulnerability, and if so, marking the corresponding to-be-fixed vulnerability as ignored, and ending the life cycle of the security vulnerability.

5. The host vulnerability lifecycle management method of claim 4, wherein, The step of the system or manual detection of whether the to-be-fixed vulnerability is a non-handling vulnerability, and if so, marking the corresponding to-be-fixed vulnerability as ignored, and ending the life cycle of the security vulnerability further comprises the steps of: single or batch marking of the to-be-fixed vulnerability that does not need to be handled as an ignored state, and ending the life cycle of the security vulnerability. 6.The host vulnerability lifecycle management method of claim 1, wherein, The step of marking a security vulnerability detected by a system as a to-be-fixed vulnerability comprises the steps of: detecting the generation of the security vulnerability, and automatically marking the generated security vulnerability as a to-be-fixed vulnerability.

7. A host vulnerability lifecycle management system, characterized by, It comprises: a marking unit for marking a security vulnerability detected by a system as a to-be-fixed vulnerability; a conversion unit for setting the to-be-fixed vulnerability that is not fixed beyond a predetermined time threshold as a timeout un-fixed vulnerability; The first detection unit is configured to detect whether the timeout unpatched vulnerability has been repaired, and if yes, end the life cycle of the security vulnerability; otherwise, re-label the timeout unpatched vulnerability as the to-be-patched vulnerability. The first detection unit is specifically configured to: The system timing automatically verifies the to-be-patched state of the timeout unpatched vulnerability, and if the system verifies that the timeout unpatched vulnerability is still in the to-be-patched state, detects whether the verification times of the timeout unpatched vulnerability exceed a preset threshold of verification times, or detects whether the verification time of the timeout unpatched vulnerability exceeds a preset threshold of verification time. If yes, the timeout unpatched vulnerability is re-labeled as the to-be-patched vulnerability. The conversion unit is specifically configured to: System timing is performed on the to-be-patched state of the labeled to-be-patched vulnerability. It is detected whether the system timing of the corresponding to-be-patched vulnerability exceeds the predetermined time threshold, and if yes, the to-be-patched vulnerability is changed to the timeout unpatched vulnerability.

8. The host vulnerability lifecycle management system of claim 7, wherein, Further comprising: A second detection unit is configured to detect whether the to-be-patched vulnerability has been repaired, and if yes, end the life cycle of the security vulnerability.

9. The host vulnerability lifecycle management system of claim 7, wherein, The first detection unit is further configured to: Manually verify whether the timeout unpatched vulnerability is in the to-be-patched state, and if yes, re-label the timeout unpatched vulnerability as the to-be-patched vulnerability, otherwise output that the security vulnerability has been repaired, and end the life cycle of the security vulnerability.

10. The host vulnerability lifecycle management system of claim 7, wherein, Further comprising a vulnerability ignoring unit, the vulnerability ignoring unit is configured to: The system detects or manually detects whether the to-be-patched vulnerability is a vulnerability that does not need to be handled, and if yes, labels the corresponding to-be-patched vulnerability as ignored, and ends the life cycle of the security vulnerability.

11. The host vulnerability lifecycle management system of claim 10, wherein, The vulnerability ignoring unit is specifically configured to: Single or batch label the to-be-patched vulnerability that does not need to be handled as ignored, and end the life cycle of the security vulnerability.

12. The host vulnerability lifecycle management system of claim 7, wherein, The labeling unit is specifically configured to: Detect the generation of the security vulnerability, and automatically label the generated security vulnerability as a to-be-patched vulnerability.

13. A storage medium, characterized by A computer program for executing the host vulnerability life cycle management method of any one of claims 1-6.

14. A computer device, comprising: A storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the computer program to implement the host vulnerability life cycle management method of any one of claims 1-6.

Images