A hypervisor layer-based cloud operating system image automatic vulnerability verification and repair method

Abstract

The application discloses a kind of cloud operating system image automation vulnerability verification and repair method based on Hypervisor layer, comprising: creating read-only basic snapshot using Btrfs file system write-time copy feature in Hypervisor layer, and configuring hardware auxiliary monitoring according to dynamic allocation of test environment by security level;Based on reflink technology, incremental snapshot and millisecond-level rollback are realized;Through large language model combined with vulnerability knowledge graph, the semantic verification of captured structured vulnerability log is carried out;Resource metadata is collected from cloud platform configuration interface to build cloud environment dependency graph, and graph neural network is used to analyze risk propagation path and calculate repair priority;According to priority, automatic repair is executed through infrastructure as code tool.The application realizes closed-loop safety verification mechanism with high isolation, high verification efficiency and high determination accuracy, and is suitable for large-scale cloud environment image security protection.

Description

Technical Field

[0001] This application belongs to the field of cloud computing security technology, specifically involving an automated vulnerability verification and remediation method for cloud operating system images based on the Hypervisor layer. Background Technology

[0002] As the deployment scale of cloud computing technology continues to expand, the number of operating system images in cloud platforms is growing rapidly, and image security issues are receiving increasing attention. Statistics show that the number of security vulnerabilities in cloud environments is increasing at an average annual rate of approximately 23%, with virtualization escape vulnerabilities, incorrect permission configurations, and input validation flaws constituting the main threat types. Against this backdrop, cloud platform operators face several practical challenges.

[0003] Currently, vulnerability verification and remediation methods for cloud operating system images mainly rely on two technical approaches. The first approach is represented by traditional vulnerability scanning tools such as Nessus and OpenVAS. Their core mechanism is based on static matching of known vulnerabilities using a predefined feature rule base. The verification process lacks deep awareness of runtime triggering conditions, making it difficult to effectively capture logical vulnerabilities that require specific system states to be exposed. Furthermore, they are not well adapted to the isolation characteristics of multi-tenant architectures in cloud environments. The second approach is the fuzzing solutions for cloud environments that have emerged in recent years, such as template-based fuzzing request generation methods and fuzzing methods targeting the operating system kernel. These methods have improved the coverage of dynamic testing to some extent, but their test environment construction still generally adopts the mode of full snapshot cloning or complete virtual machine copying. This has inherent defects such as long environment construction time, large storage resource consumption, and low rollback efficiency, making it difficult to support large-scale, high-concurrency image verification tasks.

[0004] However, the aforementioned existing technologies still have some limitations when applied to large-scale cloud operating system image security verification scenarios.

[0005] First, the isolation mechanism of the testing environment is not yet sufficient. Traditional vulnerability testing is usually performed directly inside the physical host or virtual machine. If a vulnerability is successfully triggered during the test, there is a risk of affecting the host machine or other tenant virtual machines, especially when virtualization escape vulnerabilities are involved, this risk is more prominent.

[0006] Secondly, the efficiency of test environment construction and recovery is low. Existing solutions mostly use full snapshots for environment cloning when performing image verification. Cloning a single operating system image typically takes several minutes and incurs significant storage space overhead. After the verification task is completed, environment rollback also relies on full data recovery, which is difficult to meet the timeliness requirements of large-scale concurrent verification.

[0007] Third, the accuracy of vulnerability verification needs improvement. Static analysis methods struggle to capture the actual triggering conditions of vulnerabilities at runtime, while dynamic fuzzing methods have limited ability to understand vulnerability semantics, leading to a high false positive rate. This high false positive rate forces security teams to invest significant manpower in verification, thus affecting the timeliness of vulnerability response and handling.

[0008] Fourth, the vulnerability remediation process lacks an effective priority assessment mechanism and automated closed-loop capability. After a vulnerability is discovered, the determination of remediation priorities relies heavily on human experience, and the remediation operation and verification processes are disconnected, failing to form an automated closed-loop process from vulnerability discovery to remediation verification.

[0009] In summary, existing technologies have room for improvement in terms of isolation, verification efficiency, verification accuracy, and repair loop. Summary of the Invention

[0010] To address the problems of insufficient test environment isolation, low snapshot rollback efficiency, high false positive rate in vulnerability identification, and disconnection in the remediation process in existing technologies for large-scale cloud image security verification, this application provides an automated vulnerability verification and remediation method for cloud operating system images based on the Hypervisor layer, so as to achieve a closed-loop security verification mechanism with high isolation, high verification efficiency, and high judgment accuracy.

[0011] To achieve the above technical objectives, this application specifically employs the following technical solution: One aspect of this application provides an automated vulnerability verification and remediation method for cloud operating system images based on the Hypervisor layer, comprising the following steps: S1. At the Hypervisor layer, the Btrfs file system interface is called through the Hypervisor management interface to create a read-based snapshot of the base operating system image by utilizing the copy-on-write feature. S2. Based on the security level of the operating system image under test, dynamically allocate test environments with corresponding isolation levels and configure hardware-assisted monitoring measures; S3. Based on the read-only basic snapshot, use the reflink technology of the Btrfs file system to create a read-write subvolume for the test environment. During the vulnerability verification process, record the write operation through Btrfs incremental snapshots, and perform a rollback by deleting the old subvolume and recreating the snapshot after verification. S4. When the Hypervisor layer captures vulnerability triggering behavior, it generates a structured vulnerability log and submits the structured vulnerability log to the large language model. The large language model then combines the pre-built vulnerability knowledge graph to perform semantic similarity retrieval and reasoning verification to determine the authenticity of the vulnerability. S5. Collect metadata of image, volume, network, and security group resources from the cloud platform configuration management API, parse the dependencies between resources to construct a cloud environment dependency graph, and use a graph neural network to perform risk propagation analysis on the cloud environment dependency graph. Combine CVSS score, number of dependent nodes, and public network exposure factor to calculate risk propagation score and output vulnerability remediation priority ranking. S6. Based on the priority of vulnerability remediation, generate and execute automated remediation solutions using Infrastructure as Code (ICC) tools.

[0012] In one implementation, configuring the hardware-assisted monitoring measures in step S2 includes: Enable Intel VT-x or AMD-V CPU virtualization extensions and allocate an independent virtual machine control structure region for each test virtual machine; Configure IOMMU device-level address translation isolation to force all DMA operations to undergo address translation through IOMMU, thereby preventing test virtual machines from directly accessing the host machine's physical memory.

[0013] In one implementation, step S2, which involves dynamically allocating a test environment with the appropriate isolation level based on the security level of the operating system image under test, includes: When the security level is normal, a container-level isolated environment is created using the Docker engine; When the security level is high-risk, create a MicroVM-level isolated environment using Firecracker or Cloud-Hypervisor; When testing for virtualization escape vulnerabilities, create a complete virtual machine using QEMU-KVM.

[0014] In one implementation, generating a structured vulnerability log in step S4 includes: Capture crash dump information through the Hypervisor's debugging interface, and extract system call sequences and memory state snapshots; The extracted information is formatted into a structured log containing timestamps, process information, system call parameters, and register status.

[0015] In one implementation, step S4, which involves using a large language model in conjunction with a pre-built vulnerability knowledge graph to perform semantic similarity retrieval and reasoning verification, includes: The structured vulnerability logs are converted into semantic embedding vectors using an encoder based on a large language model. The semantic embedding vector is compared with historical vulnerability cases in the vulnerability knowledge graph to obtain the most similar historical cases and their context information. Construct hint words that include current vulnerability logs and historical similar cases, and input the hint words into a large language model for inference analysis to determine the authenticity of the vulnerability.

[0016] In one implementation, the construction of the vulnerability knowledge graph in step S4 includes: Define entity types, including vulnerability instance entities, trigger condition entities, impact scope entities, and remediation solution entities; Define the relationships between entities, including the triggers relationship from vulnerability instances to triggering conditions, the effects relationship from triggering conditions to the scope of impact, and the remediation relationship from vulnerability instances to remediation solutions; The verified vulnerability information and its verification process data are written into the knowledge graph to update the confidence and attribute information of vulnerability instances.

[0017] In one implementation, step S5, which uses a graph neural network to perform risk propagation analysis on the cloud environment dependency graph, includes: Based on the cloud environment dependency graph structure, an adjacency matrix is ​​constructed, and a feature vector containing CVSS score, exposure status, and dependency degree is initialized for each node; The features of neighboring nodes are aggregated through graph convolutional layers, and the risk propagation path is calculated based on node centrality and edge weights. The final risk score is calculated by combining CVSS score, number of dependent nodes, and public network exposure factor, and the output vulnerability remediation priority is ranked accordingly.

[0018] In one implementation, the method further includes: after verification is completed, feeding back the confirmed vulnerability information and its verification process data to the vulnerability knowledge graph to form a verification closed loop.

[0019] In one implementation, the method is executed based on a Kubernetes distributed architecture, and the allocation of the test environment is accomplished through a custom Kubernetes scheduler, which schedules the task to a matching computing node according to the security level requirements of the vulnerability verification task.

[0020] In one implementation, the Infrastructure as Code tool is Terraform, and the automated remediation scheme includes tightening security group rules at the cloud platform level or embedding vulnerability mitigation configurations in an Infrastructure as Code template.

[0021] The beneficial effects of this application are as follows: In terms of verification efficiency, the incremental snapshot mechanism is implemented through the write-time copy feature of the Btrfs file system and reflink technology. The time for creating a single snapshot is reduced from minutes in the traditional solution to milliseconds, and the rollback latency is reduced to less than fifty milliseconds. Relying on the Kubernetes distributed architecture and multi-schedule collaborative mechanism, the parallel verification throughput can reach thousands of tasks per second, meeting the timeliness requirements of large-scale cloud image verification.

[0022] Second, in terms of verification accuracy, the semantic verification engine driven by the vulnerability knowledge graph and the large language model performs semantic similarity matching and contextual reasoning on the structured logs when the vulnerability is triggered and historical vulnerability cases. The false positive rate is reduced from 40% to 60% in traditional solutions to less than 10%, and the detection coverage of virtualization escape vulnerabilities is increased to more than 95%.

[0023] Third, in terms of remediation efficiency, risk propagation analysis of cloud environment dependency graph is performed by graph neural network. The priority of vulnerability remediation is dynamically calculated by combining CVSS score, number of dependent nodes and public network exposure factor. The remediation decision time is shortened from several hours to less than five minutes. With the help of infrastructure as code tools, the remediation plan is automatically generated and deployed. The closed loop cycle from discovery to remediation of high-risk vulnerabilities is compressed from several hours to minutes.

[0024] IV. In terms of system protection, the Hypervisor layer hardware-assisted virtualization monitoring and multi-level isolation mechanism ensure that the testing process does not interfere with the host machine and other tenant virtual machines. The knowledge graph feedback and update mechanism forms a continuous learning closed loop, and the cross-platform adaptation capability covers mainstream public cloud and private cloud environments. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating the automated vulnerability verification and remediation method for cloud operating system images based on the Hypervisor layer in the embodiments of this application. Detailed Implementation

[0026] The technical solution of this application will be clearly and completely described below with reference to specific embodiments. However, those skilled in the art will understand that the embodiments described below are only some embodiments of this application, not all embodiments, and are only used to illustrate this application, and should not be regarded as limiting the scope of this application. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] This application systematically reconstructs the entire vulnerability verification and remediation process by sinking it down to the Hypervisor layer. Through the organic coupling of hardware and software collaborative isolation mechanisms, native snapshot capabilities of the file system, knowledge-driven semantic analysis engine, and graph neural network propagation model, it constructs an automated pipeline covering the closed loop from vulnerability discovery to remediation.

[0028] Specifically, this involves four technical dimensions. First, leveraging the Hypervisor layer's direct control over hardware-assisted virtualization extensions, combined with the Btrfs file system's copy-on-write feature, a lightweight read-only basic snapshot is built at the host machine level. This dynamically derives container-level, MicroVM-level, or full virtual machine-level test environments based on security levels. IOMMU address translation isolation and incremental difference recording replace traditional full cloning, compressing environment building and rollback time to the millisecond level. Second, a dual-engine collaborative verification mechanism of vulnerability knowledge graph and large language model is introduced. Using system call sequences and memory state snapshots captured by the Hypervisor as input, similar historical cases are retrieved from the knowledge graph through semantic embedding vectors. The large language model then combines context to infer the authenticity of the vulnerability, while simultaneously feeding the judgment results back into the knowledge graph to form a continuous optimization loop. Third, a graph neural network is used to model resource dependencies collected from the cloud platform's configuration management interface. The propagation risk of vulnerabilities along dependency edges is calculated by aggregating neighbor node features using an adjacency matrix. A dynamic remediation priority ranking is generated by combining CVSS scores, the number of dependent nodes, and public network exposure factors. Fourth, relying on the Kubernetes custom scheduler, the distributed distribution of mixed isolated tasks of containers and MicroVMs is realized. The priority ranking results are transformed into automated remediation actions such as security group policy tightening and image building signature verification through the Infrastructure as Code tool, ultimately forming a closed loop without human intervention from the vulnerability trigger point to the verification of the remediation effect.

[0029] In one specific implementation, a method for automated vulnerability verification and remediation of cloud operating system images based on the Hypervisor layer includes the following steps: S1. At the Hypervisor layer, the Btrfs file system interface is called through the Hypervisor management interface to create a read-based snapshot of the base operating system image using the Copy-on-Write (CoW) feature.

[0030] Specifically, a snapshot creation command is issued to the Btrfs file system through the Hypervisor management interface. Taking a KVM virtualization environment as an example, the Hypervisor management interface can be the virSnapshotCreate interface. After receiving the snapshot creation command, the Btrfs file system generates a read subvolume based on the copy-on-write mechanism of the base operating system image. This read-only subvolume is the read-only base snapshot. The read-only base snapshot saves the metadata information and necessary block pointer references of the base operating system image, but does not perform a complete copy of all data blocks of the base operating system image. Therefore, there is a significant difference between the storage space occupied by the original image and the storage space occupied by the read-only base snapshot. For example, if the original image occupies 100GB of storage space, the corresponding storage space occupied by the read-only base snapshot can be controlled to about 2GB. The read-only base snapshot shares the data blocks already existing in the original image through block pointer references, thereby achieving efficient utilization of storage space.

[0031] To reduce the storage overhead caused by mirror cloning, the system adopts Btrfs incremental snapshot sharing technology. The implementation of Btrfs incremental snapshot sharing technology includes two steps: establishing a basic snapshot sharing mechanism and performing incremental data management.

[0032] Step 1: Establish a basic snapshot sharing mechanism.

[0033] A read-only snapshot of the base operating system image is created at the storage layer, namely the read-only base snapshot generated in step S1. When writable storage space is needed for the test environment, a read-write sub-volume based on the read-only base snapshot is created for each test environment. The creation of the read-write sub-volume is implemented using the reflink technology of the Btrfs file system. The reflink technology allows the read-write sub-volume to share the same data blocks with the read-only base snapshot. During the creation process, only the metadata information and block pointer references of the read-only base snapshot are copied, and no physical copying of data blocks is performed. Multiple test environments can create their own read-write sub-volumes based on the same read-only base snapshot. Each read-write sub-volume is independent of the others, and all share the data blocks in the read-only base snapshot through the reflink technology.

[0034] Step 2: Perform incremental data management.

[0035] During vulnerability verification, incremental write operations generated by each test environment are recorded. The Btrfs file system only copies the corresponding data block for exclusive use by the test environment when the test environment actually modifies the data block using the copy-on-write mechanism. Unmodified data blocks continue to be accessed by multiple test environments through shared references. Furthermore, differential compression technology can be used to compress the differential data generated by incremental writes, further reducing storage space usage.

[0036] By using Btrfs incremental snapshot sharing technology, in scenarios where a large number of test environments are running in parallel, the storage space overhead is only the sum of the size of the base operating system image and the amount of incremental data written to each test environment, which significantly reduces the storage resource consumption during the vulnerability verification process on the cloud platform.

[0037] S2. Based on the security level of the operating system image under test, dynamically allocate the test environment with the corresponding isolation level and configure hardware-assisted monitoring measures.

[0038] The allocation of the testing environment is performed through a custom Kubernetes scheduler. The custom Kubernetes scheduler receives vulnerability verification tasks, parses the security level requirement parameters carried in the tasks, and schedules the tasks to compute nodes that meet the isolation requirements based on these parameters. The compute nodes are pre-deployed with corresponding isolated runtime environments, including container runtimes, MicroVM runtimes, and full virtual machine runtimes.

[0039] Specifically, when the security level of the operating system image under test is determined to be at the normal level, a container-level isolation environment is created using the Docker engine, and Cgroup resource limit parameters are configured. The container-level isolation environment shares the host operating system kernel, and isolation between containers is achieved through namespaces and control groups to achieve isolation of processes, networks, file systems, and resource usage.

[0040] When the security level of the operating system image under test is determined to be high-risk, a MicroVM-level isolated environment is created using Firecracker or Cloud-Hypervisor. The MicroVM-level isolated environment leverages hardware virtualization to provide an independent guest kernel, offering higher isolation strength than container-level isolated environments while maintaining a lighter resource footprint and faster startup speed.

[0041] When vulnerability verification tasks involve testing and verifying virtualization escape vulnerabilities, a complete virtual machine isolation environment is created using QEMU-KVM. This complete virtual machine isolation environment provides a full virtual hardware abstraction layer, including independent virtual firmware, virtual devices, and guest operating system kernels, and further configures hardware-assisted monitoring interfaces to capture abnormal behavior of the virtualization layer.

[0042] Hardware-assisted monitoring measures are configured for the allocated test environment, including: First, enable Intel VT-x or AMD-V CPU virtualization extensions. Once enabled, allocate an independent virtual machine control structure (VM) area for each test virtual machine. This VM control structure area stores the CPU state information of the test virtual machine, including register context, execution control domain, and exit control domain. This independent VM control structure area ensures complete isolation of the CPU state between the test virtual machine and the host machine; any modifications made by the test virtual machine to the CPU state will not be leaked to the host machine or other virtual machines.

[0043] Second, configure IOMMU device-level address translation isolation. Enabling IOMMU forces all direct memory access operations initiated by the test virtual machine to undergo address translation via IOMMU. IOMMU maps the guest physical address visible to the test virtual machine to the host physical address, blocking the test virtual machine from bypassing the address translation mechanism to directly access the host physical memory, thereby preventing the test virtual machine from using direct memory access operations to perform unauthorized access to the host memory space.

[0044] In one optional implementation, hardware-assisted monitoring measures also include configuring Intel SGX security extensions. After configuring Intel SGX security extensions, a hardware-level encrypted protection area, referred to as the Enclave, is partitioned within the test environment's memory. Critical and sensitive data involved in the testing process is stored within the Enclave. Neither the host operating system nor the hypervisor can access the plaintext data stored within the Enclave, thus providing confidentiality and integrity protection for critical data in the test environment at the hardware level.

[0045] S3. Create read-write subvolumes based on read-only basic snapshots, perform incremental recording and rollback. After creating the read-only basic snapshot and dynamically allocating the test environment, based on the created read-only basic snapshot, the Btrfs file system's reflink technology is used to create read-write subvolumes for the allocated test environment. During the vulnerability verification process, write operations are recorded through the Btrfs incremental snapshot mechanism. After the vulnerability verification is completed, the test environment is rolled back by deleting the old subvolume and recreating the snapshot.

[0046] In some embodiments, creating a read-write subvolume based on a read-only basic snapshot specifically involves: When writable storage space is needed for the test environment, a read-write subvolume is created based on a pre-created read-only base snapshot using the snapshot creation command provided by the Btrfs file system. This read-write subvolume serves as the root file system for the test environment. Because the Btrfs file system supports reflink, the operation of creating the read-write subvolume only copies the metadata information and necessary block pointer references of the read-only base snapshot; it does not perform a complete copy of the base image data blocks. The read-write subvolume shares the same data blocks as the read-only base snapshot; new data blocks are allocated only when a write operation occurs, according to the copy-on-write mechanism.

[0047] Multiple test environments can create their own read-write sub-volumes based on the same read-only base snapshot. Each read-write sub-volume is independent of the others, but all share common data blocks from the read-only base snapshot. In scenarios with a large number of parallel test tasks, the storage space overhead for the same base operating system image is only the base image size plus the amount of data incrementally written by each test environment, significantly reducing storage resource consumption.

[0048] In some embodiments, the write operation of Btrfs incremental snapshot records during the vulnerability verification process includes: During test environment operation, all write operations occurring within the test environment are captured by the Btrfs file system, and modified data blocks are written to new storage locations according to the copy-on-write mechanism. The Btrfs file system automatically maintains the reference relationship between the original data blocks and the modified data blocks, forming incremental difference records. The system can create intermediate snapshots at any point in the vulnerability verification process to save the environment state of a specific testing phase for backtracking analysis of the vulnerability triggering process.

[0049] In some embodiments, performing a rollback after vulnerability verification includes: When a round of vulnerability verification is completed and the test environment needs to be restored to its initial state to receive the next verification task, the read-write subvolume corresponding to this round of verification is deleted using Btrfs file system commands. After the read-write subvolume is deleted, the incremental write data blocks associated with it are marked as reclaimable space because they are no longer referenced by any snapshot. Subsequently, the read-write subvolume with the same name is recreated based on the same read-only snapshot using Btrfs file system commands. The newly created read-write subvolume is completely consistent with the initial test environment state. The above operation of deleting the old subvolume and recreating the snapshot only involves updating metadata and redirecting block pointers at the file system level; the actual copying and erasing of data blocks are not performed.

[0050] S4. Vulnerability Authenticity Verification Based on LLM and Vulnerability Knowledge Graph When the Hypervisor layer captures vulnerability triggering behavior, it generates a structured vulnerability log and submits it to the LLM. The LLM then uses a pre-built vulnerability knowledge graph to perform semantic similarity retrieval and reasoning verification to determine the authenticity of the vulnerability.

[0051] In some embodiments, generating a structured vulnerability log includes: capturing crash dump information generated when a vulnerability is triggered via the Hypervisor's debugging interface. The crash dump information contains low-level data such as the process context that triggered the vulnerability, processor register states, memory mapping information, and exception vectors. System call sequences and memory state snapshots are extracted from the crash dump information. The system call sequences record the names, parameters, and return values ​​of system calls initiated by the process before and after the vulnerability is triggered; the memory state snapshot records stack frame content, key heap memory data structures, and instruction pointer addresses. The extracted system call sequences and memory state snapshots are formatted into a structured log with predetermined fields. The structured log includes a timestamp field, a process information field, a system call parameter field, and a register state field. The timestamp field indicates the precise moment the vulnerability was triggered; the process information field includes the process identifier, process name, and user identifier; the system call parameter field records the parameter names and values ​​of each system call in key-value pairs; and the register state field records the values ​​of general-purpose registers, the instruction pointer register, and the flag register.

[0052] In some embodiments, LLM combines a pre-built vulnerability knowledge graph with semantic similarity retrieval and reasoning verification, including: 1) Call the LLM encoder to convert the structured vulnerability logs into semantic embedding vectors. The encoder maps the text descriptions, parameter sequences, and state information in the structured logs to a fixed-dimensional vector space, so that semantically similar vulnerability behaviors correspond to vectors that are close in distance in the vector space.

[0053] 2) Perform similarity retrieval between the semantic embedding vector and historical vulnerability cases stored in the vulnerability knowledge graph. Each historical vulnerability case in the vulnerability knowledge graph has its corresponding semantic embedding vector pre-calculated and stored. Similarity retrieval uses metrics such as cosine similarity or Euclidean distance to recall one or more historical vulnerability cases from the vulnerability knowledge graph that are most similar to the current semantic embedding vector, and obtains the contextual information of each historical vulnerability case, including the vulnerability instance's CVE ID, trigger condition description, impact scope, and remediation plan.

[0054] 3) Construct hints containing the current vulnerability log content and retrieved historical similarity case information. The hints are organized according to a predefined template, including a structured description of the current vulnerability triggering behavior, CVE IDs and trigger condition comparison information for similar historical vulnerabilities, and instructions requesting LLM to perform inference and judgment. The constructed hints are then input into LLM for inference analysis. Based on the security domain knowledge learned during pre-training and the historical case reference information provided in the hints, LLM outputs a judgment result regarding whether the current vulnerability triggering behavior corresponds to a real vulnerability, the vulnerability severity level, and a recommended remediation solution.

[0055] In some embodiments, the relationships between entities in the vulnerability knowledge graph are predefined. These relationships include the `triggers` relationship from vulnerability instance entities to triggering condition entities, indicating that a specific vulnerability is caused by a specific triggering condition; the `affects` relationship from triggering condition entities to affected scope entities, indicating that a specific triggering condition will affect a specific scope; and the `remediates` relationship from vulnerability instance entities to remediation solution entities, indicating that a specific vulnerability can be remediated by a specific remediation solution.

[0056] In some embodiments, after verification, the confirmed vulnerability information and its verification process data are fed back to the vulnerability knowledge graph, forming a verification closed loop. Specifically, the confirmed vulnerability information and verification process data are written into the vulnerability knowledge graph. The write operation updates the confidence attribute and attribute information of the corresponding vulnerability instance entity, and adds newly discovered triggering condition patterns as triggering condition entities to the vulnerability knowledge graph. High-quality verification cases are periodically extracted from the vulnerability knowledge graph, and the LLM is fine-tuned and optimized using the extracted verification cases. At the same time, the verification rules and similarity thresholds are updated, forming a closed loop of verification result feedback and continuous model optimization.

[0057] S5. Vulnerability Priority Assessment Based on GNN Dependency Graph Metadata of image, volume, network, and security group resources is collected from the cloud platform configuration management API. The dependencies between resources are parsed to construct a cloud environment dependency graph. GNN is used to perform risk propagation analysis on the cloud environment dependency graph. The risk propagation score is calculated by combining CVSS score, number of dependent nodes, and public network exposure factor to output the priority ranking of vulnerability remediation.

[0058] In some embodiments, cloud environment dependency graph construction includes two steps: collecting cloud resource metadata and constructing the dependency graph structure.

[0059] Step 1: Collect cloud resource metadata Metadata for various resources in the cloud environment is collected through the cloud platform's configuration management API. Taking AWS cloud platform as an example, resource metadata can be collected through the AWS Config service API; taking OpenStack cloud platform as an example, resource metadata can be collected through the OpenStack SDK. The collected resource types include image resources, volume resources, network resources, and security group resources. Image resource metadata includes the image identifier, image name, base operating system type, and associated snapshot information; volume resource metadata includes the volume identifier, target virtual machine identifier, and capacity information; network resource metadata includes the virtual private cloud identifier, subnet identifier, routing table configuration, and network ACL rules; and security group resource metadata includes the security group identifier, inbound rule list, and outbound rule list.

[0060] After collecting resource metadata, the dependencies between resources are resolved. Dependencies include reference relationships, access relationships, and propagation relationships. A reference relationship indicates that one resource directly references another resource in its configuration, such as a virtual machine instance referencing an image resource, or a volume resource being mounted to a virtual machine instance. An access relationship indicates that one resource can access another resource via a network protocol, such as network reachability between virtual machines under different security groups. A propagation relationship indicates that exploit behavior may spread along the path of resource association, such as propagating from an infected virtual machine to other virtual machines mounted on the same volume.

[0061] Step 2: Construct the dependency graph structure Each collected resource is mapped to a node in the cloud environment dependency graph. Each node has a unique node identifier and node type attribute. The dependencies between resources are mapped to edges in the cloud environment dependency graph. Each edge has a starting node identifier, a target node identifier, and an edge type attribute. Attribute information is attached to nodes, including resource type, associated vulnerability CVE ID, CVSS score, exposure status, and dependency degree. Attribute information is attached to edges, including dependency weight values. Dependency weight values ​​can be assigned based on the access frequency between resources, network bandwidth, or the strictness of security rules.

[0062] GNN risk propagation analysis includes two steps: constructing an adjacency matrix and node features, and calculating the risk propagation score.

[0063] Step 1: Construct the adjacency matrix and node features An adjacency matrix is ​​constructed based on the cloud environment dependency graph structure. The dimension of the adjacency matrix is ​​equal to the number of nodes in the graph, and the matrix elements represent whether there is an edge connection between corresponding nodes and the weight of the edge. A feature vector is initialized for each node in the cloud environment dependency graph. The feature vector includes a CVSS score dimension, an exposure state dimension, and a dependency degree dimension. The CVSS score dimension is the CVSS v3 score of the vulnerability corresponding to the node; if the node's resource has no associated vulnerability, it is assigned a value of zero. The exposure state dimension is a Boolean value or a grade value indicating whether the node is exposed to the public network. The dependency degree dimension is the sum of the node's in-degree and out-degree values ​​in the dependency graph.

[0064] The graph convolutional layer aggregates the features of neighboring nodes. It takes the adjacency matrix and the current feature vector of each node as input, aggregates the features of each node's neighboring nodes through graph convolution operations, and updates the hidden layer representation vector of the node. Multiple graph convolutional layers can be stacked to capture the impact of multi-hop dependencies on risk propagation.

[0065] Step 2: Calculate the risk transmission score The risk propagation path is calculated based on node centrality metrics and edge weights. Node centrality metrics, such as degree centrality, betweenness centrality, or eigenvector centrality, are used to assess the structural importance of nodes in the dependency graph. The final risk score is calculated by combining the CVSS score, dependent node values, and public network exposure factor.

[0066] Based on the calculated final risk scores, each vulnerability is sorted in descending order, and a priority list for vulnerability remediation is output. Each record in the priority list includes the vulnerability CVE ID, the identifier of the affected resource, the final risk score, and the recommended remediation order.

[0067] In some embodiments, to further improve the dynamic accuracy of vulnerability remediation priorities, time series modeling is used to predict the probability of a vulnerability being exploited in the next 72 hours.

[0068] 1) Constructing temporal features Historical vulnerability exploitation data was extracted as training samples. This data includes the daily number of exploit attempts, successful exploitation records, and corresponding threat intelligence reports for each CVE vulnerability since its public disclosure date. A time-series dataset was constructed, comprising CVSS score, public disclosure days, and threat intelligence signal dimensions. The CVSS score dimension represents the vulnerability's CVSS v3 score; the public disclosure days dimension represents the cumulative number of days from the vulnerability's public disclosure on NVD to the current date; and the threat intelligence signal dimension represents the quantitative value of vulnerability exploitation activity ratings released by security vendors or threat intelligence platforms. The constructed time-series dataset was input into an LSTM network for time-series pattern learning. The LSTM network uses a gating mechanism to capture the long-term and short-term dependencies of vulnerability exploitation probability with public disclosure days, outputting predicted probability values ​​for vulnerability exploitation in future time periods.

[0069] 2) Based on the trained time-series prediction model, output the predicted probability of each vulnerability being exploited in the next 72 hours. Weight and fuse the vulnerability exploitation probability prediction with the risk propagation score calculated by the GNN in step S5 to calculate a comprehensive priority score.

[0070] The vulnerability remediation order is dynamically adjusted based on the calculated comprehensive priority score, and the resource allocation strategy is updated synchronously. This dynamic priority update mechanism ensures that remediation resources are prioritized for vulnerabilities that have both a high risk of propagation and a high probability of near-term exploitation, achieving optimal allocation of security response resources and efficient execution of the vulnerability remediation closed loop.

[0071] S6. Based on the priority of vulnerability remediation, generate and execute automated remediation solutions using Infrastructure as Code (ICC) tools.

[0072] Based on the vulnerability remediation priority output in step S5, an automated remediation plan is generated and executed using the Infrastructure as Code (IaC) tool. Terraform is selected as the IaC tool. The automated remediation plan includes tightening security group rules at the cloud platform level or embedding vulnerability mitigation configurations into IaC templates.

[0073] Specifically, the system analyzes the vulnerability entries with the highest risk scores in the vulnerability remediation priority list, extracting the affected resource identifiers and vulnerability CVE IDs. Based on the vulnerability CVE IDs, it retrieves the corresponding remediation entity from the vulnerability knowledge graph, obtaining the patch file identifier, configuration change content, or mitigation measure description. When the remediation plan involves network access control adjustments, Terraform generates security group rule change code to tighten inbound security group rules to block the network ports or protocols relied upon by vulnerability exploitation. When the remediation plan involves operating system or application configuration modifications, Terraform solidifies the configuration changes into parameter settings in the infrastructure i.e. code template, ensuring that subsequent resource instances created based on the same image inherit the remediated security configurations. After previewing and confirming the automated remediation plan generated by Terraform, it automatically executes the apply operation, completing the deployment of vulnerability remediation or mitigation measures at the cloud platform infrastructure level.

[0074] In some embodiments, the method of this application is executed based on the Kubernetes distributed architecture. The allocation of the test environment is completed through a custom Kubernetes scheduler, which schedules the task to a matching computing node according to the security level requirements of the vulnerability verification task.

[0075] The distributed automated vulnerability verification module implements hybrid isolation scheduling at the container level and MicroVM level, which includes two steps: configuring a custom scheduler and executing scheduling decisions.

[0076] Step 1: Configure a custom scheduler Deploy a custom scheduler component in the Kubernetes control plane. This custom scheduler component runs as a standalone Pod in the kube-system namespace, working in parallel with the default Kubernetes scheduler. Configure scheduler plugins, including the HypervisorIsolation scoring plugin, the SnapshotSharing sharing optimization plugin, and the SecurityLevelMatch security level matching plugin.

[0077] The HypervisorIsolation scoring plugin is used to evaluate the degree to which each compute node meets the isolation requirements of the test environment. Compute nodes with hardware-assisted virtualization support capabilities receive higher scores; compute nodes with Firecracker or Cloud-Hypervisor runtime deployed receive additional scores; and compute nodes with a large number of remaining allocable MicroVM instances receive even higher scores.

[0078] The SnapshotSharing optimization plugin is used to evaluate the support level of each compute node for Btrfs incremental snapshot sharing technology. Compute nodes with Btrfs file system backend and read-only base snapshot storage paths mounted receive higher scores; compute nodes with local caches of the target base snapshot receive the highest scores to reduce cross-node snapshot transfer overhead.

[0079] The SecurityLevelMatch plugin matches the security level requirements declared in a vulnerability verification task with the isolation capabilities provided by the compute nodes. A perfect match between the security level requirements and the compute node capabilities earns full marks; compute node capabilities exceeding the requirements but not perfectly matching earn partial marks; and compute node capabilities falling short of the requirements earn zero marks.

[0080] After completing the scheduler plugin configuration, enable the HypervisorIsolation scoring plugin, SnapshotSharing sharing optimization plugin, and SecurityLevelMatch security level matching plugin in the custom scheduler configuration file.

[0081] Step 2: Execution of scheduling decisions When a vulnerability verification task is submitted to a Kubernetes cluster, the task is declared as a custom resource definition, including parameters such as the identifier of the operating system image to be tested, security level requirements, and isolation type preferences. A custom scheduler receives the vulnerability verification task and parses the security level requirement parameters carried in the task. The security level requirement parameters can be set to normal, high-risk, or involve virtualization escape.

[0082] Select the appropriate isolation strategy based on the type of operating system image to be tested. If the image type is a Linux container image with a normal security level, select the container-level isolation strategy; if the image type is a complete Linux system image with a high security level, select the MicroVM-level isolation strategy; if the image type involves testing for virtualization escape vulnerabilities, select the complete virtual machine isolation strategy.

[0083] The configured scoring plugins are invoked to score and rank the candidate compute nodes in the cluster. The HypervisorIsolation, SnapshotSharing, and SecurityLevelMatch plugins output the score values ​​for each node, and the combined scores are weighted and summed to calculate the final scheduling score. A custom scheduler schedules the vulnerability verification task to the compute node with the highest final scheduling score, and the corresponding runtime deployed on the compute node completes the creation of the test environment and the execution of the vulnerability verification task.

[0084] Example 1 This embodiment provides a specific application scenario for implementing automated vulnerability verification and remediation methods in a private cloud platform.

[0085] A mid-sized technology company operates a private cloud platform containing approximately 2,000 virtual machines, running over ten operating system image templates, including CentOS and Ubuntu. The daily image verification requirement is approximately 800. The original vulnerability verification solution involved cloning a full snapshot, which took 3-5 minutes each time, resulting in a daily false positive rate of 45% for the security team.

[0086] The specific process is as follows: Step 1: Building the Hypervisor Layer Isolation Test Environment The system, acting as an administrator, invokes the KVM / QEMU Hypervisor API to create a read-only base snapshot of the CentOS 7.9 base image under test: `btrfs subvolume snapshot -r / images / centos7.9 / snapshots / centos7.9_ro_001` Snapshot creation takes less than 80 milliseconds, and storage overhead is only 0.3% of the original image (approximately 30MB of difference data).

[0087] Based on this read-only snapshot, the system simultaneously starts three MicroVM test environments (using Firecracker): testenv_001, testenv_002, and testenv_003.

[0088] Each MicroVM is configured with: 1 vCPU, 512MB of memory, and an isolated network namespace, ensuring complete isolation from the host CPU state via Intel VT-x.

[0089] Step 2: Incremental snapshots and millisecond-level rollback During vulnerability verification, all write operations are recorded in the incremental difference file. After verification, a rollback is performed: `btrfs subvolume delete / testenv_001&&btrfs subvolume snapshot / snapshots / centos7.9_ro_001 / testenv_001` Rollback takes less than 45 milliseconds, allowing for immediate reception of the next verification task. This is approximately 4600 times faster than traditional full snapshot cloning (approximately 210 seconds).

[0090] Step 3: Collaborative Validation of Knowledge Graph and Large Model The system automatically captures the crash stacks and system call sequences of each MicroVM, generates structured vulnerability logs, and submits them to the LLM semantic analysis engine (GPT-4 level).

[0091] LLM combines historical similar CVE cases in the knowledge graph to determine whether the vulnerability is a real vulnerability (confidence level), severity level, and recommended remediation solution.

[0092] Verification results: Among 200 test samples, 32 real vulnerabilities were confirmed, with only 3 false positives, resulting in a false positive rate of 8.6% (compared to 40%-60% for traditional methods).

[0093] Step 4: Prioritization of GNN-driven vulnerabilities The system extracts the image dependency graph (nodes: image, volume, network, security group) from the OpenStack API and aggregates the features of adjacent nodes using the GCN layer.

[0094] The risk score is calculated by combining the CVSS score (α=0.5), the number of dependent nodes (β=0.3), and the public network exposure factor (γ=0.2). RiskScore = CVSS × (1 + dep_nodes × 0.1) × exposure_factor The top vulnerability is CVE-Simulation-Internal Network-SMB Remote Code Execution, with a RiskScore of 9.2.

[0095] Step 5: Automated IaC Repair The system automatically generates a remediation plan using Terraform: tightening security group rules at the OpenStack level and embedding the SMBv1 protocol disabling configuration in the IaC template.

[0096] After the fix was completed, the system re-executed the incremental snapshot verification to confirm that the vulnerability could no longer be triggered.

[0097] Implementation results: The daily verification capacity increased from 80 to 1,500 (18.75 times faster); the false positive rate decreased from 45% to 8.6%; and the closed-loop time from high-risk vulnerability discovery to remediation was shortened from an average of 4.2 hours to 35 minutes.

[0098] Example 2 This embodiment provides a specific application scenario for implementing an automated vulnerability verification and remediation method in a multi-tenant public cloud platform.

[0099] A public cloud service provider operates a multi-tenant cloud platform for enterprise customers. The platform has about 500 tenant VPCs and a total of about 10,000 operating system images, covering various types such as Windows Server and Linux. It is necessary to perform security verification on tenant images before they are put on the shelf to ensure that there are no high-risk issues such as virtualization escape vulnerabilities. At the same time, it is necessary to ensure that the testing process is strictly isolated and does not affect the virtual machines of other tenants on the same physical server.

[0100] The specific process is as follows: Step 1: Hardware-assisted virtualization isolation environment configuration For each image to be tested, the system configures the following hardware-assisted isolation measures via the Hypervisor API: ① Intel VT-x / AMD-V: Allocate an independent vCPU state region (VMCS) for each test MicroVM to ensure that VM escape attempts cannot modify the host CPU registers; ② Intel SGX: Provides hardware-level memory encryption protection for critical data in the test environment, so that even the host administrator cannot read the memory contents of the test environment; ③ IOMMU: All DMA operations are addressed via IOMMU to prevent the test VM from directly accessing the host machine's physical memory.

[0101] Windows Hyper-V isolation is used when testing Windows images; KVM+Firecracker MicroVM isolation is used when testing Linux images.

[0102] Step 2: Large-scale parallel incremental snapshot verification The Kubernetes master scheduler receives 10,000 image verification tasks, and a custom scheduler distributes them to the corresponding nodes based on the image type and security level.

[0103] Each compute node runs 8-16 MicroVMs concurrently, and multiple test environments share the same base image data block using Btrfs reflink technology. btrfs subvolume snapshot / snapshots / ubuntu2204_ro / testenv / vuln_001 btrfs subvolume snapshot / snapshots / ubuntu2204_ro / testenv / vuln_002 Storage space is only required for the base image size (approximately 2GB), compared to 20TB for traditional solutions. Parallel verification of 10,000 images is completed within 2 hours (compared to 3-5 days for traditional serial solutions).

[0104] Step 3: Knowledge Graph Validation and GNN Prioritization The system has built a vulnerability knowledge graph with more than 50,000 nodes (based on historical CVE data), covering major vulnerability types such as virtualization escape, permission configuration errors, and input validation defects.

[0105] After each MicroVM triggers a vulnerability, the LLM retrieves similar CVEs from the knowledge graph and determines the authenticity of the vulnerability by combining the runtime context.

[0106] The GNN module calculates the risk propagation path and identifies three high-risk vulnerability nodes (RiskScore ≥ 7.0): ① CVE-Simulated-Host-Virtualization Escape (RiskScore=9.4, exposed to the public network, compute node); ② CVE - Simulation - Inter-tenant - Lateral Movement (RiskScore=8.7, Cross-tenant VPC Peer Connection); ③ CVE - Simulation - Image Supply Chain - Malicious Initialization Script (RiskScore=7.2, implanted during the image building stage).

[0107] Step 4: Closed-loop automated repair The system automatically generates and executes the following solutions: ① Disable the virtualization extension of the problematic compute node and perform a firmware update; ② Check the VPC peering configuration and remove the abnormal cross-tenant policy. ③ Insert a signature verification step into the image build pipeline to prevent the execution of unsigned scripts. Once the fix is ​​complete, an automatic verification report will be generated and sent to the tenant's security administrator.

[0108] Implementation results: The verification cycle before 10,000 images are put on the platform has been shortened from 3-5 days to 2 hours; the detection rate of virtualization escape vulnerabilities has increased from 62% to 97%; and the remediation loop time has been shortened from 48 hours to 2 hours.

[0109] Although the embodiments of this application have been described above in conjunction with the accompanying drawings, this application is not limited to the specific embodiments and application fields described above. The specific embodiments described above are merely illustrative and instructive, not restrictive. Those skilled in the art can make many other forms based on the guidance of this specification and without departing from the scope of protection of the claims of this application, and these are all within the scope of protection of this application.

Claims

1. A method for automated vulnerability verification and remediation of cloud operating system images based on the Hypervisor layer, characterized in that, Includes the following steps: S1. At the Hypervisor layer, the Btrfs file system interface is called through the Hypervisor management interface to create a read-based snapshot of the base operating system image by utilizing the copy-on-write feature. S2. Based on the security level of the operating system image under test, dynamically allocate test environments with corresponding isolation levels and configure hardware-assisted monitoring measures; S3. Based on the read-only basic snapshot, use the reflink technology of the Btrfs file system to create a read-write subvolume for the test environment. During the vulnerability verification process, record the write operation through Btrfs incremental snapshots, and perform a rollback by deleting the old subvolume and recreating the snapshot after verification. S4. When the Hypervisor layer captures vulnerability triggering behavior, it generates a structured vulnerability log and submits the structured vulnerability log to the large language model. The large language model then combines the pre-built vulnerability knowledge graph to perform semantic similarity retrieval and reasoning verification to determine the authenticity of the vulnerability. S5. Collect metadata of image, volume, network, and security group resources from the cloud platform configuration management API, parse the dependencies between resources to construct a cloud environment dependency graph, and use a graph neural network to perform risk propagation analysis on the cloud environment dependency graph. Combine CVSS score, number of dependent nodes, and public network exposure factor to calculate risk propagation score and output vulnerability remediation priority ranking. S6. Based on the priority of vulnerability remediation, generate and execute automated remediation solutions using Infrastructure as Code (ICC) tools.

2. The automated vulnerability verification and remediation method for cloud operating system images based on the Hypervisor layer according to claim 1, characterized in that, The hardware-assisted monitoring measures configured in step S2 include: Enable Intel VT-x or AMD-V CPU virtualization extensions and allocate an independent virtual machine control structure region for each test virtual machine; Configure IOMMU device-level address translation isolation to force all DMA operations to undergo address translation through IOMMU, thereby preventing test virtual machines from directly accessing the host machine's physical memory.

3. The automated vulnerability verification and remediation method for cloud operating system images based on the Hypervisor layer according to claim 1, characterized in that, Step S2, which dynamically allocates the test environment with the corresponding isolation level based on the security level of the operating system image under test, includes: When the security level is normal, a container-level isolated environment is created using the Docker engine; When the security level is high-risk, create a MicroVM-level isolated environment using Firecracker or Cloud-Hypervisor; When testing for virtualization escape vulnerabilities, create a complete virtual machine using QEMU-KVM.

4. The automated vulnerability verification and remediation method for cloud operating system images based on the Hypervisor layer according to claim 1, characterized in that, Step S4, which generates a structured vulnerability log, includes: Capture crash dump information through the Hypervisor's debugging interface, and extract system call sequences and memory state snapshots; The extracted information is formatted into a structured log containing timestamps, process information, system call parameters, and register status.

5. The automated vulnerability verification and remediation method for cloud operating system images based on the Hypervisor layer according to claim 1, characterized in that, Step S4, which involves semantic similarity retrieval and inference verification using a large language model combined with a pre-built vulnerability knowledge graph, includes: The structured vulnerability logs are converted into semantic embedding vectors using an encoder based on a large language model. The semantic embedding vector is compared with historical vulnerability cases in the vulnerability knowledge graph to obtain the most similar historical cases and their context information. Construct hint words that include current vulnerability logs and historical similar cases, and input the hint words into a large language model for inference analysis to determine the authenticity of the vulnerability.

6. The automated vulnerability verification and remediation method for cloud operating system images based on the Hypervisor layer according to claim 1, characterized in that, The construction of the vulnerability knowledge graph in step S4 includes: Define entity types, including vulnerability instance entities, trigger condition entities, impact scope entities, and remediation solution entities; Define the relationships between entities, including the triggers relationship from vulnerability instances to triggering conditions, the effects relationship from triggering conditions to the scope of impact, and the remediation relationship from vulnerability instances to remediation solutions; The verified vulnerability information and its verification process data are written into the knowledge graph to update the confidence and attribute information of vulnerability instances.

7. The automated vulnerability verification and remediation method for cloud operating system images based on the Hypervisor layer according to claim 1, characterized in that, Step S5, which uses a graph neural network to perform risk propagation analysis on the cloud environment dependency graph, includes: Based on the cloud environment dependency graph structure, an adjacency matrix is ​​constructed, and a feature vector containing CVSS score, exposure status, and dependency degree is initialized for each node; The features of neighboring nodes are aggregated through graph convolutional layers, and the risk propagation path is calculated based on node centrality and edge weights. The final risk score is calculated by combining CVSS score, number of dependent nodes, and public network exposure factor, and the output vulnerability remediation priority is ranked accordingly.

8. The automated vulnerability verification and remediation method for cloud operating system images based on the Hypervisor layer according to claim 1, characterized in that, The method further includes: after verification is completed, feeding back the confirmed vulnerability information and its verification process data to the vulnerability knowledge graph to form a verification closed loop.

9. The automated vulnerability verification and remediation method for cloud operating system images based on the Hypervisor layer according to claim 1, characterized in that, The method is executed based on the Kubernetes distributed architecture. The allocation of the test environment is completed through a custom Kubernetes scheduler. The custom scheduler schedules the task to the matching computing node according to the security level requirements of the vulnerability verification task.

10. The automated vulnerability verification and remediation method for cloud operating system images based on the Hypervisor layer according to claim 1, characterized in that, The Infrastructure as Code tool is Terraform, and the automated remediation solution includes tightening security group rules at the cloud platform level or embedding vulnerability mitigation configurations in the Infrastructure as Code template.

Images