Linux-oriented vulnerability repair verification method and system and medium

Abstract

The invention discloses a Linux-oriented vulnerability repair verification method and system and a medium. The method comprises the steps of creating a test application form for a CVE vulnerability patch in a task management system, preparing a test environment for CVE vulnerability repair verification as well as a required test table, a software source and a test strategy file, and calling a tool interface to automatically trigger an assembly line; the assembly line executes the test suite in the test environment based on the test table, the software source and the test strategy file and collects an execution state, and if the execution state is failure, automatic retry can be carried out on the CVE vulnerability based on manual triggering; and finally, generating a report file, writing a verification result for the test application form in the task management system, and if the verification result is that verification is passed, issuing a service pack of the CVE vulnerability. The invention aims to realize efficient, traceable and extensible Linux vulnerability repair verification, realize full automation and intelligence of the vulnerability verification process, and improve the accuracy, traceability and expandability of verification.

Description

Technical Field

[0001] This invention relates to the field of computer security and software testing, specifically to a vulnerability remediation and verification method, system, and medium for Linux. Background Technology

[0002] With the widespread application of open-source software and the Linux operating system in cloud computing, virtualization, and server scenarios, the security issues of the Linux operating system are becoming increasingly prominent, and the work of patching and verifying security vulnerabilities (CVEs) is becoming more frequent. To ensure that vulnerability patches can correctly address security issues while avoiding the introduction of new defects or system instability, Linux operating system patches typically require rigorous testing and verification to guarantee stable operation under different environments, versions, and architectures without affecting other system functions. Currently, traditional manual verification methods have significant shortcomings. Manual testing is inefficient, time-consuming, and prone to human error, making it difficult to cover a large number of environment combinations in a short period. The vulnerability patching verification process involves multiple stages, including patch compilation, environment setup, vulnerability reproduction, verification execution, and result archiving. Manual operation is not only cumbersome but also suffers from difficulties in auditing and poor traceability. While existing automated verification solutions improve testing efficiency to some extent, most exist only as single-point scripts, lacking unified scheduling and pipeline management capabilities. Such solutions typically cannot automate the entire patch verification process and are weak in exception handling, logging, and result archiving, making it difficult to support large-scale parallel verification needs. Currently, determining whether a security vulnerability has been patched still primarily relies on manual comparison and judgment. This method is not only time-consuming but also prone to overlooking potential problems. Because developers patch vulnerabilities in various ways—such as modifying vulnerability trigger points or adding security functions, or adjusting interface request methods (e.g., changing GET to POST)—manual verification often struggles to identify the effectiveness of the patch and potential risks in a timely and accurate manner. Furthermore, during the verification process, if the system version or dependent components change, issues such as code rollback or patch failure can easily occur, which existing verification methods struggle to detect in a timely manner. In summary, existing technologies have the following shortcomings: 1) Manual verification methods are inefficient and have a high error rate, making it difficult to cover combined testing across multiple environments and versions; 2) Automated verification schemes are mostly single-point scripts, lacking a unified pipeline management, exception handling, and result archiving mechanism; 3) Judgment of vulnerability patch effectiveness mainly relies on manual intervention, posing a risk of omissions and misjudgments; 4) There is a lack of a systematic exception classification and handling mechanism, making it difficult to quickly locate and resolve problems during testing; 5) The ability to perform parallel verification across multiple environments, architectures, and versions is insufficient, making it difficult to meet the verification needs of complex scenarios. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide a vulnerability repair and verification method, system, and medium for Linux, addressing the aforementioned problems in the prior art. This invention aims to achieve efficient, traceable, and scalable Linux vulnerability repair and verification, realize the full automation and intelligence of the vulnerability verification process, and improve the accuracy, traceability, and scalability of verification.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A vulnerability remediation verification method for Linux includes the following steps: S101: In the task management system, create a test application form for the CVE vulnerability patch to be verified, prepare the test environment for CVE vulnerability repair verification, as well as the required test submission form, software source and test strategy file, and call the tool interface to automatically trigger the pipeline. S102, the pipeline executes the test suite in the test environment based on the test submission form, software source, and test strategy file and collects the execution status. If the execution status is failure, proceed to step S103; if the execution status is success, proceed to step S104. S103, proceed with the corresponding follow-up processing based on the failure situation. If it is a repairable problem, then automatically retry the CVE vulnerability based on manual triggering of step S102; otherwise, generate a report file, write the verification result to the test application form in the task management system, write the storage path of the report file to the task metadata, and if the verification result is successful, release the patch package for the CVE vulnerability, end and exit. S104: Generate a report file, write the verification result to the test application form in the task management system, write the storage path of the report file to the task metadata, and if the verification result is successful, release the patch package for the CVE vulnerability.

[0005] Optionally, before step S101, the method includes periodically checking CVE vulnerability release information through a polling script. If a new CVE vulnerability is detected, the process jumps to step S101 to trigger automatic CVE vulnerability remediation verification.

[0006] Optionally, preparing the test environment for CVE vulnerability remediation verification in step S101 includes using automated scripts to prepare a test environment consistent with the required version of the CVE vulnerability in a specified test cluster, wherein the nodes in the test cluster are physical machines, containers, or virtual machines.

[0007] Optionally, the step S101 of automatically triggering the pipeline by calling the tool interface includes: S201: Construct an HTTP request based on the given username and API key, pipeline server address, job name corresponding to the test request form, and authentication token, and send the HTTP request using curl. S202, wait for the execution number returned by the pipeline server, and write the test request form into the initial running status in the task management system.

[0008] Optionally, step S102, where the pipeline executes the test suite and collects execution status data in the test environment based on the test submission form, software source, and test strategy file, includes four stages: ① Installation verification: Installing the software packages required for vulnerability patch verification using the package manager installation command executed through test cases and recording installation logs; ② Service verification: Checking the startup and running status of critical system services through test cases; ③ Functional verification: Executing test cases for specified core functions; ④ CVE vulnerability verification testing: Verifying and reproducing vulnerability patches for CVE vulnerabilities through test cases. In each of the four stages, the pipeline uploads the return codes, standard output, standard error, system monitoring data, and timestamp information of the test cases to the target server system for aggregation and tracking. If any test case fails to execute, the pipeline will collect more detailed log information according to a preset strategy, including privilege escalation log levels and capturing crash dump logs for subsequent problem localization and analysis.

[0009] Optionally, step S103 includes: S301, parse the status code returned by the test suite to determine the failure type: If the failure type is test submission failure, check the reason for the test submission failure, update the test submission, and re-upload the test submission; proceed to step S302. If the failure type is software source failure, check the reason for the software source failure and update the software source information; proceed to step S302. If the failure type is failure to generate a text file when testing the strategy file, perform permission correction; proceed to step S302. If the failure type is test case cannot be executed, analyze and repair the unexecutable test cases. If the failure type is an unknown status code, analyze the reason for pipeline termination and exceptions, and repair them. If the failure type is test environment connection failure, analyze the test environment network connection function. If the network connection function is abnormal, repair the network connection function and proceed to step S302. If the failure type is all test items succeeded but there are manual test items, perform manual testing and test analysis and proceed to step S303. If the failure type is that there are test item failures and there are manual test items, analyze the failed test items and perform manual testing and test analysis and proceed to step S303. If the failure type is that there are no additional manual test items but there are test item failures, analyze the failed test items and proceed to step S303. S302, based on manually triggered jump step S102 to automatically retry CVE vulnerabilities; S303, determine if a retry is needed. If a retry is needed, proceed to step S302; otherwise, generate a report file, write the verification result to the test application in the task management system, write the storage path of the report file to the task metadata, and end and exit.

[0010] Optionally, when writing the verification result for the test application form in the task management system in step S303, the verification result includes one of the following: verification failure TFAIL_HAND containing manual testing, verification pass TPASS_HAND containing manual testing, verification pass TPASS without manual testing, and verification warning.

[0011] The present invention also provides a vulnerability remediation verification system for Linux, including a microprocessor and a memory interconnected thereto, wherein the microprocessor is programmed or configured to execute the vulnerability remediation verification method for Linux.

[0012] The present invention also provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute the Linux-oriented vulnerability remediation verification method by a processor.

[0013] The present invention also provides a computer program product, including a computer program or instructions that are programmed or configured to execute the Linux-oriented vulnerability remediation verification method via a processor.

[0014] Compared with existing technologies, the present invention can achieve the following beneficial effects: (1) It realizes the full automation of the vulnerability repair verification process. From patch reception, environment preparation, test case execution to result archiving, no manual intervention is required, which greatly improves the verification efficiency, reduces human participation, and reduces the risk of human error; (2) It establishes a complete anomaly classification and handling mechanism. By collecting the status of key nodes in the pipeline operation and reporting them to centralized monitoring, combined with fault classification rules, it realizes the automatic identification and handling of anomalies in the testing process, significantly reduces the fault location time, and improves the accuracy and reliability of testing; (3) It supports parallel verification of multiple environments, multiple architectures, and multiple versions. Through the automated pipeline, it realizes large-scale testing and meets the requirements of complex scenarios. (3) It meets the verification requirements of the test environment and improves the comprehensiveness and efficiency of the test; (4) It is deeply integrated with the existing enterprise-level task system, realizes the unified management and tracking of tasks, forms a complete vulnerability repair closed loop, and ensures the traceability and auditability of test results; (5) It adopts a structured report generation mechanism, records test results and log information in Excel, YAML and other formats, which is convenient for machine reading and analysis and suitable for manual review, thus improving the quality and usability of test reports; (6) It provides a rollback and snapshot retesting mechanism, generates an environment snapshot before verification, and provides the function of automatically installing physical machines with the Cobbler tool. When the test fails, the environment state can be automatically restored, ensuring the consistency and repeatability of the test environment. In summary, the vulnerability remediation verification method for Linux of this invention requires no manual intervention throughout the entire process, from patch reception and environment preparation to verification execution and result archiving. It also possesses capabilities such as multi-architecture and multi-version parallel verification, unified logging and result auditing, and automatic anomaly classification and handling. This enables an efficient, traceable, and scalable vulnerability remediation verification process, achieving full automation and intelligence in the vulnerability verification process, and improving the accuracy, traceability, and scalability of verification. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the basic process of the method in an embodiment of the present invention. Detailed Implementation

[0016] To enable those skilled in the art to better understand the technical solutions of the present invention, the technical solutions of the present invention will be further described in detail below with reference to the accompanying drawings in the embodiments of the present invention.

[0017] This embodiment of the vulnerability remediation verification method for Linux includes triggering actions, execution pipeline, enterprise project management system (status), follow-up processing and automated test results, including the complete execution path from creating a verification request to archiving results and the process of handling abnormal branches. For example... Figure 1As shown, the vulnerability remediation verification method for Linux in this embodiment includes the following steps: S101, in the task management system, create a test application form for the CVE vulnerability patch to be verified (which can be created automatically or manually), prepare the test environment for CVE vulnerability repair verification (including ISO files and runtime environment, etc.), as well as the required test submission form, software source and test strategy file (yaml), and call the tool interface to automatically trigger the pipeline. S102, the pipeline executes the test suite in the test environment based on the test submission form, software source, and test strategy file and collects the execution status. If the execution status is failure, proceed to step S103; if the execution status is success, proceed to step S104. S103, proceed with the corresponding follow-up processing based on the failure situation. If it is a repairable problem, then automatically retry the CVE vulnerability based on manual triggering of step S102; otherwise, generate a report file, write the verification result to the test application form in the task management system, write the storage path of the report file to the task metadata, and if the verification result is successful, release the patch package for the CVE vulnerability, end and exit. S104: Generate a report file, write the verification result to the test application form in the task management system, write the storage path of the report file to the task metadata, and if the verification result is successful, release the patch package for the CVE vulnerability.

[0018] Before step S101 in this embodiment, the method also includes periodically detecting CVE vulnerability release information through a polling script. If a new CVE vulnerability is detected, the process jumps to step S101 to trigger automatic CVE vulnerability repair verification.

[0019] In this embodiment, step S101, preparing the test environment for CVE vulnerability remediation verification, includes using automated scripts to prepare a test environment consistent with the required version of the CVE vulnerability in a specified test cluster. The nodes in the test cluster can be physical machines, containers, or virtual machines (VMs). The automated scripts prepare a penetration environment in the specified test cluster (physical machine, container, or VM), check the base image version, and ensure that the environment is consistent with the version under test; if isolation is required, a temporary VM / container snapshot is created.

[0020] In this embodiment, step S101, which calls the tool interface to automatically trigger the pipeline, includes: S201, based on the given username and API key, pipeline server address, job name corresponding to the test request, and authentication token, construct an HTTP request and send it using curl; for example, in this embodiment, the pipeline uses the Jenkins system, and the format of the constructed HTTP request is:

[0021] in, <username>and<API_TOKEN> These are the username and API key, respectively.<JENKINS_URL> ,<JOB_NAME> and<TOKEN_NAME> The pipeline server address, the job name corresponding to the test request form, and the authentication token are respectively provided. <parameter1>and <parameter2>These are parameters for the HTTP request. <value1>and <value2>To assign values ​​to the parameters; S202, wait for the execution number (execution_id) returned by the pipeline server, and write the test request form to the initial running status (running) in the task management system.

[0022] The pipeline concurrently schedules and executes test cases on multiple nodes. In this embodiment, step S102, where the pipeline executes test suites in the test environment based on the test submission table, software source, and test strategy file, and collects the execution status, includes four stages: ① Installation and verification: Install the necessary packages for vulnerability patching verification by executing package manager installation commands through test cases and record the installation log, such as: yum install -y package-version or yum update -y package-version, etc.; ② Service verification: Check the startup and running status of key system services through test cases; ③ Functional verification: Execute test cases for the specified core functions; ④ CVE vulnerability verification testing: Verify and reproduce the vulnerability patches for CVE vulnerabilities using test cases; At each of the four stages, the pipeline uploads the return codes, standard output (stdout), standard error (stderr), system monitoring data, and timestamp information of the test cases to the target server system for aggregation and tracking. If any test case fails to execute, the pipeline will collect more detailed log information according to a preset strategy, including privilege escalation log levels and crash dump logs for subsequent problem localization and analysis.

[0023] like Figure 1 As shown, step S103 in this embodiment includes: S301, parse the status code returned by the test suite to determine the failure type: If the failure type is test submission failure, check the reason for the test submission failure, update the test submission, and re-upload the test submission; proceed to step S302. If the failure type is software source failure, check the reason for the software source failure and update the software source information; proceed to step S302. If the failure type is failure to generate a text file when testing the strategy file, perform permission correction; proceed to step S302. If the failure type is test case cannot be executed, analyze and repair the unexecutable test cases. If the failure type is an unknown status code, analyze the reason for pipeline termination and exceptions, and repair them. If the failure type is test environment connection failure, analyze the test environment network connection function. If the network connection function is abnormal, repair the network connection function and proceed to step S302. If the failure type is all test items succeeded but there are manual test items, perform manual testing and test analysis and proceed to step S303. If the failure type is that there are test item failures and there are manual test items, analyze the failed test items and perform manual testing and test analysis and proceed to step S303. If the failure type is that there are no additional manual test items but there are test item failures, analyze the failed test items and proceed to step S303. S302, based on manually triggered jump step S102 to automatically retry CVE vulnerabilities; S303, determine if a retry is needed. If a retry is needed, proceed to step S302; otherwise, generate a report file, write the verification result to the test application in the task management system, write the storage path of the report file to the task metadata, and end and exit.

[0024] Step S103 of this embodiment includes automatic classification based on return codes and log content, and synchronizing error details to the enterprise-level task system. Example rules: (1) R&D concerns errors: failure to parse test submission form; failure to detect source; (2) Test development (test developers) concerns errors: if the pipeline fails in the generation of execution list (txt / yaml) stage, record failure to generate txt file; trigger configuration file verification and regeneration or manual inspection. If some test cases cannot be executed on the target environment due to missing dependencies, mark them as test cases that cannot be executed, and attach a list of missing dependencies for regression / completion. If an unknown status code or exception stack is detected, trigger the manual intervention workflow and attach status markers and log summaries. (3) Test concerns errors: test environment connection failure; all test items are successful but there are manual test items; there are test items that fail and there are manual test items; there are no additional manual tests but there are test items that fail.

[0025] In subsequent processing and manual intervention, problems that can be automatically repaired (such as temporary network issues) are automatically retried and recorded. Problems that cannot be automatically resolved generate manual tasks in the enterprise project management system and are forwarded to the relevant teams. These tasks are marked with various statuses such as TFAIL_HAND, TPASS_HAND, TPASS, and Warning, and include a list of failed test cases and error steps. For example, in step S303 of this embodiment, when writing the verification result to the test request form in the task management system, the verification result includes one of the following: verification failure (TFAIL_HAND) containing manual testing, verification pass (TPASS_HAND) containing manual testing, verification pass (TPASS) without manual testing, and verification with a warning (Warning).

[0026] After the pipeline is completed, the generated report file in this embodiment is: result_cve_date.xlsx (machine-readable + human-reviewable). In the task management system, a success message (test-success) is written based on the result, and the storage path of the report file is written to the task metadata. The patch package is then released. In the project management system, a test request number for a failure (test-failed) is written based on the result, and a new test request (bug request) is created in the project management system.

[0027] In summary, the vulnerability remediation verification method for Linux in this embodiment achieves automated verification, anomaly location, and manual work order triggering by triggering actions, executing pipelines, collecting status data, classifying and handling faults, and archiving automated results. It can quickly verify whether the patch fixes the target CVE vulnerability, ensure the consistency of the test environment, and generate auditable results. This embodiment of the vulnerability remediation verification method for Linux mainly includes the following steps: creating a verification task and preparing test cases and environment; updating patches or software packages for the target system / software; triggering automated pipeline execution (which can be triggered via HTTP / curl or message queue); collecting status data of key nodes during pipeline operation and reporting the status to centralized monitoring (enterprise project management or similar systems); classifying failures based on execution results (parsing failure, detection failure, build / distribution failure, test case execution failure, unknown status code, execution node connection failure, etc.); taking different follow-up actions for different failure types (automatic retry, rollback, configuration correction, manual intervention); generating test results when verification is successful and pushing the results to the automated test result repository, while generating txt, yaml, and report files for auditing; automatically creating / updating defect tickets or triggering manual triggering processes when necessary. This embodiment of the method can solve the problems of low verification efficiency and strong reliance on manual intervention in existing technologies: traditional vulnerability remediation verification relies on manual execution and judgment, resulting in long testing cycles, high error rates, and difficulty in supporting frequent vulnerability remediation needs. This embodiment addresses the problem of insufficient coverage in existing technologies: existing methods have limited coverage in combined testing across multiple architectures, versions, and environments, failing to ensure stable operation of patches in all target environments. This embodiment also addresses the problem of low automation in existing technologies: existing automated verification often relies on scattered, single-point scripts, lacking a unified scheduling and pipeline management mechanism, and cannot achieve full automation from patch reception to result archiving. Furthermore, this embodiment addresses the problem of inadequate anomaly handling and result auditing in existing technologies: current solutions lack a comprehensive anomaly classification and handling mechanism, failing to automatically identify, record, and retry issues such as execution interruptions and environmental anomalies, and also lacking auditable log and report output. Finally, this embodiment addresses the problem of insufficient accuracy in vulnerability remediation judgment in existing technologies: due to diverse remediation methods (such as modifying request methods, replacing function logic, etc.), existing methods mainly rely on manual judgment of whether vulnerabilities have been patched, easily leading to misjudgments or omissions. Finally, this embodiment addresses the problem of difficulty in archiving and tracing verification results in existing technologies: existing systems lack a unified result archiving and visualization mechanism, making verification history and execution logs difficult to audit, which is detrimental to subsequent regression verification and problem localization. The main features of the method in this embodiment include: (1) a fully automated verification pipeline architecture with a closed loop throughout the entire process.Existing technologies are mostly limited to single-point scripts or local tools, while the method in this embodiment constructs an end-to-end automated verification pipeline, which for the first time completely connects "patch monitoring and task creation → dynamic environment preparation and deployment → concurrent execution of multi-dimensional test cases → intelligent classification and handling of anomalies → structured archiving of results and synchronization of system status". This architecture realizes a closed-loop management from vulnerability patch release to verification result feedback, truly replacing multiple links in the traditional process that rely on manual connection, which is a fundamental innovation of the method in this embodiment at the system design level. (2) Intelligent anomaly handling mechanism based on multi-dimensional status acquisition and rule engine. In view of the pain points of existing technologies that "only report errors, do not handle them" or rely on manual judgment, the method in this embodiment innovatively introduces a real-time status acquisition and reporting system and a rule-based automatic fault classification engine. This mechanism not only monitors the return codes, log outputs, and system indicators of each key node in the pipeline in real time, but also automatically classifies failures into different types such as "R&D concern", "testing concern", and "testing concern" according to preset rules (such as log characteristics and error codes), and triggers differentiated automated processing strategies (such as automatic retry, configuration correction, environment rollback, or creation of manual work orders of a specified type). This achieves a leap from "error recording" to "problem diagnosis and initial routing", significantly shortening the fault location and recovery time. (3) Deeply integrated result governance and collaborative feedback system. Unlike traditional test systems that run independently and output isolated report files, the method in this embodiment achieves deep bidirectional integration with enterprise-level project management / task systems, forming an innovative collaborative feedback loop: Real-time status synchronization: The status of verification tasks (running, success, failure, and classification) is written back to the project management system in real time, achieving full transparency of the process. Structured result archiving: Automatically generates structured test reports that are both machine-readable (such as YAML) and human-reviewable (such as Excel), and stores them in association. Automated process triggering: Based on the verification results, the system can automatically create defect work orders (Bugs), update patch release status, or trigger manual review processes in the project management system, directly transforming the verification results into subsequent actions of R&D and operations, forming a complete control loop of "verification-feedback-processing".

[0028] Furthermore, this embodiment also provides a vulnerability remediation and verification system for Linux, including a microprocessor and a memory interconnected, wherein the microprocessor is programmed or configured to execute the vulnerability remediation and verification method for Linux. This embodiment also provides a computer-readable storage medium storing a computer program or instructions programmed or configured to execute the vulnerability remediation and verification method for Linux via a processor. This embodiment also provides a computer program product, including a computer program or instructions programmed or configured to execute the vulnerability remediation and verification method for Linux via a processor.

[0029] Those skilled in the art will understand that the technical solutions provided by this invention may take the form of a method, system, or computer program product. Therefore, this invention may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this invention may take the form of a computer program product embodied on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce an implementation of the flowchart... Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0030] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention. < / username>

Claims

1. A vulnerability remediation verification method for Linux, characterized in that, Includes the following steps: S101: In the task management system, create a test application form for the CVE vulnerability patch to be verified, prepare the test environment for CVE vulnerability repair verification, as well as the required test submission form, software source and test strategy file, and call the tool interface to automatically trigger the pipeline. S102, the pipeline executes the test suite in the test environment based on the test submission form, software source, and test strategy file and collects the execution status. If the execution status is failure, proceed to step S103; if the execution status is success, proceed to step S104. S103, Perform corresponding follow-up processing based on the failure situation. If it is a repairable problem, automatically retry the CVE vulnerability based on the manual triggering of the jump step S102. Otherwise, generate a report file, write the verification result to the test application form in the task management system, write the storage path of the report file to the task metadata, and if the verification result is successful, release the patch package for the CVE vulnerability, end and exit. S104: Generate a report file, write the verification result to the test application form in the task management system, write the storage path of the report file to the task metadata, and if the verification result is successful, release the patch package for the CVE vulnerability.

2. The vulnerability remediation and verification method for Linux according to claim 1, characterized in that, Before step S101, the process also includes periodically checking CVE vulnerability release information through a polling script. If a new CVE vulnerability is detected, the process jumps to step S101 to trigger automatic CVE vulnerability remediation verification.

3. The vulnerability remediation and verification method for Linux according to claim 1, characterized in that, Step S101 involves preparing a test environment for CVE vulnerability remediation verification, which includes using automated scripts to prepare a test environment in a specified test cluster that is consistent with the required version of the CVE vulnerability. The nodes in the test cluster can be physical machines, containers, or virtual machines.

4. The vulnerability remediation and verification method for Linux according to claim 1, characterized in that, Step S101, which involves calling the tool interface to automatically trigger the pipeline, includes: S201: Construct an HTTP request based on the given username and API key, pipeline server address, job name corresponding to the test request form, and authentication token, and send the HTTP request using curl. S202, wait for the execution number to be returned by the pipeline server, and write the test request form into the initial running status in the task management system.

5. The vulnerability remediation and verification method for Linux according to claim 1, characterized in that, Step S102 involves the pipeline executing test suites and collecting execution status data in the test environment based on the test submission form, software source, and test strategy file. This includes four phases: ① Installation verification: Installing the necessary software packages for vulnerability patching verification using the package manager's installation commands via test cases and recording installation logs; ② Service verification: Checking the startup and running status of critical system services using test cases; ③ Functional verification: Executing test cases for specified core functions; ④ CVE vulnerability verification testing: Verifying and reproducing CVE vulnerability patches using test cases. In each of these four phases, the pipeline uploads the test case return codes, standard output, standard error, system monitoring data, and timestamp information to the target server system for aggregation and tracking. If any test case fails to execute, the pipeline will collect more detailed log information according to the preset strategy, including privilege escalation log level and capturing crash dump logs for subsequent problem localization and analysis.

6. The vulnerability remediation and verification method for Linux according to claim 1, characterized in that, Step S103 includes: S301, parse the status code returned by the test suite to determine the failure type: If the failure type is test submission failure, check the reason for the test submission failure, update the test submission, and re-upload the test submission; proceed to step S302. If the failure type is software source failure, check the reason for the software source failure and update the software source information; proceed to step S302. If the failure type is failure to generate a text file when testing the strategy file, perform permission correction; proceed to step S302. If the failure type is test case cannot be executed, analyze and repair the unexecutable test cases. If the failure type is an unknown status code, analyze the reason for pipeline termination and exceptions, and repair them. If the failure type is test environment connection failure, analyze the test environment network connection function. If the network connection function is abnormal, repair the network connection function and proceed to step S302. If the failure type is all test items succeeded but there are manual test items, perform manual testing and test analysis and proceed to step S303. If the failure type is that there are test item failures and there are manual test items, analyze the failed test items and perform manual testing and test analysis and proceed to step S303. If the failure type is that there are no additional manual test items but there are test item failures, analyze the failed test items and proceed to step S303. S302, based on manually triggered jump step S102 to automatically retry CVE vulnerabilities; S303, determine if a retry is needed. If a retry is needed, proceed to step S302; otherwise, generate a report file, write the verification result to the test application in the task management system, write the storage path of the report file to the task metadata, and end and exit.

7. The vulnerability remediation and verification method for Linux according to claim 6, characterized in that, In step S303, when writing the verification result for the test application form in the task management system, the verification result includes one of the following: verification failure TFAIL_HAND containing manual testing, verification pass TPASS_HAND containing manual testing, verification pass TPASS without manual testing, and verification warning.

8. A vulnerability remediation and verification system for Linux, comprising a microprocessor and a memory interconnected, characterized in that, The microprocessor is programmed or configured to execute the vulnerability remediation verification method for Linux as described in any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the Linux-oriented vulnerability remediation verification method as described in any one of claims 1 to 7 via a processor.

10. A computer program product, comprising a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the Linux-oriented vulnerability remediation verification method as described in any one of claims 1 to 7 via a processor.

Images