Container self-healing safety method, device, apparatus, storage medium and program product

Abstract

This application provides a container self-healing security method, apparatus, device, storage medium, and program product. The method includes: collecting system behavior events during container runtime and generating an event stream based on the system behavior events; the system behavior events include at least process creation, file access, and network connection; constructing a dynamic behavior graph based on the event stream; obtaining a target behavior graph based on the dynamic behavior graph, and generating an anomaly score based on the deviation between the target behavior graph and a preset graph; and triggering a state recovery mechanism based on the anomaly score to roll back the container's runtime state. By capturing system behavior events during container runtime, the dynamic behavior graph transforms the event stream into a graph structure of nodes and edges. The anomaly score of the dynamic behavior graph is analyzed to trigger the state recovery mechanism. From event collection to anomaly analysis to state recovery, real-time detection, response, and proactive self-healing of threats during container runtime are achieved, enabling automatic recovery within minutes.

Description

Technical Field

[0001] This application relates to the field of computer security monitoring technology, and in particular to a container self-healing security method, device, equipment, storage medium, and program product. Background Technology

[0002] With the widespread adoption of container technology in cloud-native architectures, its dynamic, transient, and highly isolated nature poses unprecedented challenges to traditional security measures. Container environments typically run on distributed, elastically scalable cloud platforms. Their short lifecycles, complex resource isolation, and the ability of attackers to bypass traditional security mechanisms through techniques such as container escape and stealthy process injection make them particularly vulnerable. For example, in critical industries such as finance and telecommunications, containers are frequently used to deploy high-concurrency microservice applications, and their runtime security directly impacts business continuity and data asset protection.

[0003] However, attackers may gradually penetrate the system through multi-stage attacks, such as initial intrusion, lateral movement, and persistent residence. Existing security solutions are difficult to capture the dynamic evolution of behavioral patterns when dealing with unknown threats such as advanced persistent threats (APTs) and zero-day attacks. In addition, the high dynamism of container environments requires security responses to be real-time and non-intrusive; otherwise, it may lead to business interruption or waste of resources. Summary of the Invention

[0004] This application provides a container self-healing safety method, apparatus, device, storage medium, and program product to achieve timely response and seamless recovery.

[0005] In a first aspect, embodiments of this application provide a container self-healing safety method, comprising:

[0006] Collect system behavior events during container runtime and generate an event stream based on these events; system behavior events include at least process creation, file access, and network connection.

[0007] Constructing dynamic behavior graphs based on event streams;

[0008] The target behavior map is obtained based on the dynamic behavior map, and an anomaly score is generated based on the degree of deviation between the target behavior map and the preset map.

[0009] Based on the anomaly score, a state recovery mechanism is triggered to roll back the runtime state of the container.

[0010] In one embodiment, based on anomaly scoring, a state recovery mechanism is triggered to roll back the container's runtime state, specifically including:

[0011] Based on the comparison results of the anomaly score and the preset threshold, determine whether to perform a full rollback or partial repair on the container;

[0012] Perform a full rollback or partial recovery on the container, specifically including:

[0013] If the anomaly score is greater than or equal to the first preset value, a full rollback is performed on the container to restore the container's running state to the previous trusted checkpoint.

[0014] If the anomaly score is less than the first preset value but greater than or equal to the second preset value, then perform a partial recovery on the container, isolate the abnormal process, and save the container's running state.

[0015] In one embodiment, the method further includes:

[0016] If the anomaly score is less than the second preset value, the container's system behavior event will be marked as a low-risk event and written to the log system.

[0017] In one embodiment, constructing a dynamic behavior graph based on an event stream includes:

[0018] Parse the event stream to obtain the entities in the event stream and the interaction relationships between the entities;

[0019] Map entities to graph nodes and the interaction relationships between entities to graph edges;

[0020] A dynamic behavior graph is constructed based on graph nodes and graph edges.

[0021] In one embodiment, a dynamic behavior graph is constructed based on graph nodes and graph edges, specifically including:

[0022] Based on graph nodes and graph edges, obtain the behavior graph at the current moment;

[0023] Based on the behavior graph at the current moment and the system behavior events at the next moment, update the attribute information of graph nodes and graph edges to obtain a dynamic behavior graph.

[0024] In one embodiment, an anomaly score is generated based on the degree of deviation between the target behavior map and a preset map, including:

[0025] The node attributes in the target behavior graph are feature-encoded to obtain node features; the node attributes include at least process name and file type.

[0026] Anomaly scores are generated based on the structural information of node features and target behavior graphs, as well as pre-set graphs.

[0027] The preset graph is the distribution of node attributes and edge relationships of the container in its normal state.

[0028] In one embodiment, an anomaly score is generated based on node features, structural information of the target behavior graph, and a preset graph, specifically including:

[0029] Based on the structural information and node features of the target behavior graph, the feature information of neighboring nodes is reconstructed through a graph attention network.

[0030] Based on the preset graph and the feature information of neighboring nodes, the reconstruction error of the dynamic behavior graph is calculated;

[0031] Anomaly scores are obtained based on reconstruction errors.

[0032] In one embodiment, obtaining the target behavior map based on the dynamic behavior map includes:

[0033] The target behavior map is obtained from the dynamic behavior map based on preset conditions; the preset conditions include preset periods or preset events.

[0034] In one embodiment, collecting system behavior events during container runtime specifically includes:

[0035] Based on events triggered within the container, event context information is obtained from the container's kernel data structure; the context information includes at least the process name, username, container name, call parameters, file path, and network 5-tuple;

[0036] After filtering or aggregating the event context information, the system behavior events are obtained.

[0037] In one embodiment, generating an event stream based on system behavior events includes:

[0038] Transform system behavior events into six-tuples that include time;

[0039] Arrange the six tuples sequentially according to time to obtain the event stream; where the event stream is an ordered sequence of events.

[0040] In one embodiment, a dynamic behavior graph is constructed based on graph nodes and graph edges, specifically including:

[0041] Different weights are assigned to node-level, edge-level, and subgraph-level features, and the aggregation strategy is dynamically adjusted through an attention mechanism.

[0042] By capturing node sequences within a time window through subgraph-level attention, and constructing a dynamic behavior graph based on the node sequences, the temporal evolution characteristics of attack behavior can be identified.

[0043] Secondly, embodiments of this application provide a container self-healing safety device, comprising:

[0044] The acquisition module is used to collect system behavior events during container runtime and generate an event stream based on these events; system behavior events include at least process creation, file access, and network connection.

[0045] Build modules are used to construct dynamic behavior graphs based on event streams;

[0046] The processing module is used to generate anomaly scores based on the degree of deviation between the dynamic behavior map and the preset map;

[0047] The execution module is used to trigger a state recovery mechanism based on anomaly scoring to roll back the runtime state of the container.

[0048] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0049] The memory stores the instructions that the computer executes;

[0050] The processor executes computer execution instructions stored in memory, causing the processor to perform any of the methods described above.

[0051] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement any of the methods described above.

[0052] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements any of the methods described above.

[0053] This application provides a container self-healing security method, apparatus, device, storage medium, and program product. The method includes: collecting system behavior events during container runtime and generating an event stream based on the system behavior events; the system behavior events include at least process creation, file access, and network connection; constructing a dynamic behavior graph based on the event stream; obtaining a target behavior graph based on the dynamic behavior graph, and generating an anomaly score based on the deviation between the target behavior graph and a preset graph; and triggering a state recovery mechanism based on the anomaly score to roll back the container's runtime state. By collecting system behavior events during container runtime, the dynamic behavior graph transforms the event stream into a graph structure of nodes and edges, outputs an anomaly score based on the deviation between the target behavior graph and the preset graph, and uses the anomaly score to trigger the state recovery mechanism. The entire process forms a closed loop, from event collection to anomaly analysis to state recovery, realizing real-time detection and repair of threats during container runtime. This solves the technical problems of existing container runtime security solutions, such as insufficient detection capability for unknown threats, delayed response, and inability to repair damage already caused, ensuring business continuity and data security. Attached Figure Description

[0054] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0055] Figure 1 A flowchart illustrating a container self-healing safety method provided in an embodiment of this application;

[0056] Figure 2 This is a schematic diagram of the structure of a container self-healing safety system provided in an embodiment of this application;

[0057] Figure 3 This is an architecture diagram of an eBPF data collector provided in one embodiment of this application;

[0058] Figure 4 A schematic flowchart illustrating the state recovery mechanism provided in one embodiment of this application;

[0059] Figure 5 This is a schematic diagram of the behavior of a container provided in an embodiment of this application;

[0060] Figure 6 This is a schematic diagram of the structure of a container self-healing safety device provided in an embodiment of this application;

[0061] Figure 7 A schematic diagram of the structure of the electronic device provided in this application.

[0062] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0063] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0064] First, let me explain the terms used in this application:

[0065] eBPF: Extended Berkeley Packet Filter, is a revolutionary technology that allows the secure execution of custom code within the operating system kernel for efficient network and performance monitoring.

[0066] GNN: Graph Neural Network, is a type of deep learning model specifically designed to process graph-structured data, capable of learning complex relationships and patterns between nodes in a graph.

[0067] CRIU: Checkpoint / Restore In Userspace, is a Linux tool that freezes and saves the state of a running process or container to disk for later recovery.

[0068] CBG: Container Behavior Graph, is a special graph structure used to dynamically represent runtime entities of containers and their interactions.

[0069] APT, or Advanced Persistent Threat, refers to a sophisticated, long-term cyberattack launched by a specific organization, which is typically well-targeted and difficult to detect.

[0070] GAT, Graph Attention Network, is an advanced GNN architecture that uses an attention mechanism to assign different weights to different neighbors when aggregating neighbor information.

[0071] SOC, Security Operations Center, is a centralized unit responsible for monitoring, preventing, detecting, investigating, and responding to cybersecurity incidents.

[0072] CNAPP, Cloud-Native Application Protection Platform, is an integrated security platform designed to protect cloud-native applications throughout their entire lifecycle.

[0073] Execve is a system call provided by the Linux / Unix kernel, used to execute a new program in the current process, that is, to replace the executable image of the current process with another executable file.

[0074] Existing technologies: Attackers may gradually penetrate a system through multi-stage attacks, such as initial intrusion, lateral movement, and persistent residence. Existing security solutions have difficulty capturing the dynamic evolution of behavioral patterns when dealing with unknown threats such as advanced persistent threats (APTs) and zero-day attacks. In addition, the high dynamism of container environments requires security responses to be real-time and non-intrusive; otherwise, it may lead to business interruption or waste of resources.

[0075] To address the shortcomings of existing technologies, the inventors of this solution have creatively designed a new approach. This solution provides a container self-healing security method to solve the problems of insufficient detection capabilities for unknown threats, delayed response, and inability to repair damage already caused by existing technologies. The specific application scenario for this application is a containerized microservice architecture in a cloud-native environment. Containers are typically deployed on orchestration platforms such as Kubernetes to run high-concurrency, dynamically scalable business applications (such as financial transaction systems and telecommunications core network services). Attackers may penetrate systems through container escape, stealthy process injection, or lateral movement, and traditional security solutions struggle to detect and repair such threats in real time.

[0076] The container self-healing security method provided in this application collects system behavior events during container runtime. A dynamic behavior graph transforms the event flow into a graph structure of nodes and edges. An anomaly score is output based on the deviation between the target behavior graph and a preset graph. This anomaly score is then used to trigger a state recovery mechanism. The entire process forms a closed loop, from event collection to anomaly analysis and state recovery, enabling real-time detection and remediation of threats during container runtime. This solves the technical problems of existing container runtime security solutions, such as insufficient detection capabilities for unknown threats, delayed response, and inability to repair damage already caused, ensuring business continuity and data security.

[0077] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0078] like Figure 1 As shown, Figure 1 This is a flowchart illustrating a container self-healing safety method provided in an embodiment of this application. Figure 2 As shown, Figure 2This is a schematic diagram of the structure of a container self-healing security system provided in one embodiment of this application. The container self-healing security system includes an eBPF Data Collector, a Container Behavior Graph Constructor, a GNN Analysis Engine, and an Adaptive Response Orchestrator. The eBPF Data Collector, acting as the system's sensor, is deployed as an eBPF program in each monitored host kernel. It is responsible for non-intrusively capturing all container-related low-level system events, such as system calls, network connections, and file accesses. It outputs a unidirectional data stream, transmitting the captured event stream to the user-space Container Behavior Graph Constructor in real time via a high-performance ring buffer. The Container Behavior Graph (CBG) builder acts as the central hub for data processing and modeling. It continuously receives event streams from the eBPF collector and, according to predefined graph construction rules, creates and updates the CBG in real-time in memory or a dedicated graph database, transforming discrete events into structured contextual information. It also receives data streams from the eBPF collector and provides the constructed dynamic behavior graph to the GNN analysis engine for analysis. The GNN analysis engine, acting as the system's decision-making brain, incorporates one or more pre-trained graph neural network models. This engine periodically (e.g., every few seconds) or triggered by key events analyzes all or part of the CBG subgraphs, outputting a quantified anomaly score for each container or key process. It obtains the behavior graph from the CBG builder as input and outputs the calculated anomaly score, transmitting it unidirectionally to the adaptive response orchestrator. The adaptive response orchestrator acts as the executor of the entire system; it receives anomaly scores from the GNN analysis engine, makes decisions and executes corresponding safety actions based on preset response policy thresholds; it receives decision instructions from the GNN analysis engine, performs checkpointing and recovery operations on containers by calling the operating system's local CRIU toolset, and communicates with external container orchestration platforms (such as Kubernetes) via API to perform broader control measures such as network isolation and resource limiting.

[0079] Please see Figure 1 The container self-healing safety method includes the following steps:

[0080] Step S101: Collect system behavior events during container runtime and generate an event stream based on the system behavior events; system behavior events include at least process creation, file access, and network connection.

[0081] Specifically, such as Figure 3 As shown, Figure 3This is an architecture diagram of an eBPF data collector provided in one embodiment of this application. The eBPF program is attached to key kernel hook points to capture system behavior events during container runtime in real time. These system behavior events specifically include metadata such as process PID / PPID, container ID, file path, and network address. The system behavior events are formed into a structured event stream and transmitted to the CBG constructor via a circular buffer. This achieves non-immersive acquisition of full behavioral data during container runtime. eBPF technology avoids the performance overhead of traditional tools (such as AuditD) by directly capturing events at the kernel level; and the structured event stream provides a high-quality data source for subsequent graph construction.

[0082] In one embodiment, step S101 specifically includes the following steps:

[0083] Based on events triggered within the container, the context information of the event is obtained from the container's kernel data structure; the context information includes at least the process name, username, container name, call parameters, file path, and network 5-tuple.

[0084] After filtering or aggregating events based on contextual information, system behavior events are obtained.

[0085] Specifically, any process within or associated with the container executes a monitored system call or kernel function. During system startup, a series of customized eBPF programs are loaded into the kernel and attached to key kernel hook points, such as system call tracepoints (sys_enter_execve), kprobes for monitoring kernel functions (security_file_open), and XDP / TC hooks for network packet processing. When an eBPF program is triggered, detailed context information about the event is extracted from kernel data structures, including process name (PID / PPID), username (UID / GID), container ID, system call parameters, return value, file path, and network address. eBPF maps are then used in kernel space to perform preliminary filtering or aggregation of high-frequency, benign events based on this context information, reducing data transfer overhead.

[0086] In one embodiment, generating an event stream based on system behavior events includes the following steps:

[0087] Transform system behavior events into six-tuples that include time.

[0088] Arrange the six tuples sequentially according to time to obtain the event stream; where the event stream is an ordered sequence of events.

[0089] Specifically, each event in the system's behavioral events can be formalized as a six-tuple. Where tn is the timestamp, τ is the event type (e.g., execve), c is the container ID, s is the subject (e.g., PID), o is the object (e.g., file path), and A is an attribute set containing detailed parameters. The events in the system behavior events are sorted in non-decreasing order by timestamp t to form an event stream, denoted as Sstream. The expression for event stream Sstream is as follows:

[0090]

[0091] in, .

[0092] In one embodiment, the eBPF data collector efficiently transmits the processed event stream to the CBG constructor in user space via a ring buffer using a shared memory mechanism.

[0093] Step S102: Construct a dynamic behavior graph based on event flow.

[0094] Specifically, the system parses entities in the event stream, such as processes, files, and network sockets, and their interactions (e.g., processes creating files, processes initiating network connections), generating a dynamic behavior graph to represent entities and their interactions during container runtime. By transforming discrete events into global context information and constructing a CBG (Context-Based Graph), isolated events are embedded into the graph structure, providing context-aware capabilities for the GNN (Generative Neural Network) model. For example, an `execve` event is represented in the graph as a causal edge between a parent and child process, while abnormal paths formed by an attacker through multi-stage operations are explicitly modeled.

[0095] Step S103: Obtain the target behavior map based on the dynamic behavior map, and generate an anomaly score based on the degree of deviation between the target behavior map and the preset map.

[0096] Specifically, the target behavior graph can be a subgraph of the container. By analyzing the graph structure of the target behavior graph, abnormal behavior patterns can be identified. The preset graph represents the distribution of node attributes and edge relationships of the container in its normal state. By comparing the preset graph and the target behavior graph, the GNN model can detect unknown threats (such as APTs) that deviate from the baseline. For example, attackers using cross-namespace file operations can create abnormal graph structures, leading to a significant increase in reconstruction errors.

[0097] Step S104: Based on the anomaly score, trigger the state recovery mechanism to roll back the running state of the container.

[0098] Specifically, based on the anomaly scoring-triggered state recovery mechanism, the system ensures that containers can quickly recover to a safe state after being attacked, avoiding business interruption and achieving minute-level self-healing of business status. For example, if an attacker injects an abnormal resource-consuming program that triggers a high anomaly score, the system will immediately roll back to an uninfected snapshot, preventing the attack from persisting.

[0099] This application collects system behavior events of containers in real time, and the dynamic behavior graph explicitly models the causal relationships between entities, enabling the graph neural network model to capture the global contextual features of attack behavior (such as illegal data flows across namespaces). The GNN model identifies anomalous behaviors deviating from the normal baseline by calculating the reconstruction error of the graph, thereby detecting unknown threats such as zero-day attacks and APTs. The state recovery mechanism triggers container state rollback based on anomaly scores, instantly restoring the system to a healthy state before the attack when a high-risk threat is detected, avoiding business interruptions caused by traditional blocking responses. For example, after an attacker injects an anomalous resource-consuming program that triggers a high anomaly score, the system can immediately roll back to an uninfected snapshot, preventing the attack from persisting. Secondly, kernel observation technologies (such as eBPF) have lower system overhead than traditional tools (such as AuditD), and the construction and analysis process of the dynamic behavior graph does not require modification of the container image or application, ensuring the compatibility and stability of the solution in the production environment. By linking threat detection with state recovery, this application achieves a paradigm shift from passive defense to proactive remediation, significantly improving the container environment's real-time detection and remediation capabilities against advanced threats.

[0100] In one embodiment, step S104 specifically includes the following steps:

[0101] Based on the comparison results of the anomaly score and the preset threshold, it is determined whether to perform a full rollback or a partial repair on the container.

[0102] Performing a full rollback or partial recovery on a container involves the following steps:

[0103] If the abnormal score is greater than or equal to the first preset value If so, a full rollback is performed on the container, restoring the container's running state to the previous trusted checkpoint.

[0104] If the abnormal score is less than the first preset value, but greater than or equal to the second preset value If so, a partial recovery is performed on the container, the abnormal process is isolated, and the container's running state is saved.

[0105] In one embodiment, the method further includes:

[0106] If the anomaly score is less than the second preset value, the container's system behavior event will be marked as a low-risk event and written to the log system.

[0107] like Figure 4 As shown, Figure 4 This is a flowchart illustrating a state recovery mechanism provided in one embodiment of this application. The adaptive response orchestrator receives anomaly scores from the GNN analysis engine and triggers the corresponding state recovery mechanism. Specifically, the input anomaly score is compared with a preset threshold to determine the appropriate response level. The formula for the state recovery mechanism function π(score) is as follows:

[0108]

[0109] When the abnormal score is less than the second preset value When a container is deemed to be facing a low-risk threat, it is logged using Alog, which marks the container's system behavior events as low-risk events and writes them to the log system.

[0110] When the abnormal score is less than the first preset value And greater than or equal to the second preset value The system considers the threat encountered by the container to be of medium risk and will take measures such as performing partial recovery on the container, isolating the abnormal process, and taking an as-forensic snapshot by calling the CRIU dump command to take a state snapshot of the target container and save its runtime state (memory, process information, etc.) as a disk file for later analysis.

[0111] When the abnormal score is greater than or equal to the first preset value If the system deems a container to be facing a high-risk threat, it performs a full rollback, restoring the container's running state to the previous trusted checkpoint (Arollback). It calls CRIU's `restore` command, using the previous trusted checkpoint—the most recent known good-state snapshot file—to restore the target container. This destroys the currently infected container process and restarts it in the state shown in the snapshot. In this example, CBG is optimized for real-time GNN analysis, making it more lightweight. Furthermore, it links the GNN analysis results with the CRIU recovery mechanism, forming a detection-response self-healing closed loop.

[0112] In one embodiment, after performing a rollback, the container's health status is checked by interacting with the Kubernetes API, and the container is forcibly restarted if necessary to ensure the eventual consistency of application-layer services, especially the reconstruction of network connections. All three state recovery mechanisms mentioned above must send alarm information to the SOC platform to facilitate timely notification to operations and maintenance personnel. This application achieves differentiated responses to different threat types by strategically selecting the rollback granularity. For example, a full rollback is used for high-risk threats (such as container escape) to ensure the complete removal of attack remnants, while for medium- and low-risk threats (such as encrypted programs with abnormal resource consumption), only the abnormal process is isolated, avoiding business interruption caused by a full recovery. This significantly improves business continuity assurance capabilities while reducing resource consumption and operational costs.

[0113] In one embodiment, step S102 includes the following steps:

[0114] Parse the event stream to obtain the entities in the event stream and the interaction relationships between the entities.

[0115] Entities are mapped to graph nodes, and the interactions between entities are mapped to graph edges.

[0116] A dynamic behavior graph is constructed based on graph nodes and graph edges.

[0117] Specifically, graph nodes represent system entities, such as processes, files, and network sockets. Each node contains attribute information, such as process name and file path. For example, an `execve` event generates a process node in the graph, whose attributes include process name and container ID. Graph edges represent graph elements that represent interactions between entities, such as process derivation (`PROC_EXEC_PROC`) and file access (`FILE_WRITE`). For example, when an attacker uses `unshare` and `setns` calls to escape container isolation, they generate illegal data flow edges across namespaces. Discrete events are transformed into graph structures through event stream parsing. For example, the `execve` event generates process nodes and their derivation edges, and the file access event generates file nodes and their access edges. Graph databases (such as Neo4j) or in-memory graph structures (such as Apache TinkerPop) dynamically update the attribute information (such as timestamps and container IDs) of nodes and edges to ensure that the graph reflects the runtime behavior of containers in real time.

[0118] The CBG constructor reads new kernel events, i.e., the event stream, from the ring buffer. For each event tuple The system analyzes and identifies the system entities (such as processes, files, and sockets) and their interactions. Based on predefined mapping rules, it creates or updates corresponding nodes and edges in the dynamic behavior graph. For example, an `execve` event generates a `PROC_EXEC_PROC` causal edge from the parent process node to the child process node. This example explicitly models the causal relationships between entities, enabling the graph neural network to capture the global contextual features of attack behavior. For instance, attackers may create abnormal paths through multi-stage operations, such as downloading malicious files, executing stealth processes, and modifying sensitive configurations; isolated event analysis struggles to identify such threats. This graph structure modeling significantly improves the detection capability of complex attack chains while reducing false positives by distinguishing between benign and malicious behavior chains. Figure 5 As shown, Figure 5 This is a schematic diagram of the behavioral graph of a container provided in an embodiment of this application. A normal graph should show process A creating file C. However, when an attacker exploits a vulnerability or scans open ports to enter the application within the container, gains local user privileges, enters the container's shell, abnormally calls process A, abnormally reads file C, or maliciously connects to external connections... Figure 5 The attacker's behavior graph can be seen from this. This example, by explicitly utilizing the relationship information between entities, can accurately understand complex, multi-stage attack chains and significantly reduce false positives.

[0119] In one embodiment, a dynamic behavior graph is constructed based on graph nodes and graph edges, specifically including the following steps:

[0120] Different weights are assigned to node-level, edge-level, and subgraph-level features, and the aggregation strategy is dynamically adjusted through an attention mechanism.

[0121] By capturing node sequences within a time window through subgraph-level attention, and constructing a dynamic behavior graph based on the node sequences, the temporal evolution characteristics of attack behavior can be identified.

[0122] Specifically, the node sequences in different time windows of the subgraph are weighted to capture the temporal evolution characteristics of attack behavior. For example, in APT attacks, the attacker's gradual infiltration pattern, such as initial intrusion - lateral movement - persistence, can be identified by subgraph-level attention. This example dynamically adjusts the feature aggregation strategy through a multi-granularity attention mechanism (node-level, edge-level, subgraph-level). For example, node-level attention strengthens the weight of access to sensitive files, edge-level attention highlights illegal data flows across namespaces, and subgraph-level attention captures the temporal evolution characteristics of APT attacks. This example significantly improves the detection accuracy of complex attack chains through the multi-granularity attention mechanism. For example, in APT attacks, attackers may break out of container isolation through unshare and setns calls and gradually infiltrate the host machine. The multi-granularity attention mechanism can identify illegal data flows across namespaces through edge-level attention and discover the attacker's gradual infiltration pattern through subgraph-level attention.

[0123] In one embodiment, a dynamic behavior graph is constructed based on graph nodes and graph edges, specifically including the following steps:

[0124] Based on graph nodes and graph edges, obtain the behavior graph at the current moment.

[0125] Based on the behavior graph at the current moment and the system behavior events at the next moment, update the attribute information of graph nodes and graph edges to obtain a dynamic behavior graph.

[0126] Specifically, at any time t, the behavior graph is defined as a directed attribute graph. Where Vt is a graph node and Et is a graph edge. The evolution of a directed attribute graph is governed by a deterministic function. Defined, this function is based on the current behavior graph Gt and the system behavior events at the next time step. This generates an updated dynamic behavior graph G(t+1), i.e. This results in a dynamically updated container behavior graph Gt that includes context.

[0127] In one embodiment, step S103 includes the following steps:

[0128] The node attributes in the target behavior graph are feature-encoded to obtain node features; the node attributes include at least process name and file type.

[0129] Anomaly scores are generated based on the structural information of node features and target behavior graphs, as well as a preset graph; where the preset graph is the distribution of node attributes and edge relationships of the container in the normal state.

[0130] Specifically, the discrete attributes of nodes in the target behavior graph, such as process name, file type, and numerical attributes, such as UID, are encoded to obtain node features, which are then converted into numerical feature vectors X that can be processed by the GNN model.

[0131] In one embodiment, an anomaly score is generated based on node features, structural information of the target behavior graph, and a preset graph, specifically including the following steps:

[0132] Based on the structural information and node features of the target behavior graph, the feature information of neighboring nodes is reconstructed through a graph attention network.

[0133] Based on the preset graph and the feature information of neighboring nodes, the reconstruction error of the dynamic behavior graph is calculated.

[0134] Anomaly scores are obtained based on reconstruction errors.

[0135] Specifically, the node features and structural information of the target behavior graph are input into a pre-trained graph autoencoder model. The GNN encoder (such as GAT) compresses the target behavior graph into a low-dimensional latent representation matrix Z. The core update formula of GAT is as follows:

[0136]

[0137] in, αij represents a new feature of node i, and αij represents the weights calculated through the attention mechanism. The decoder attempts to reconstruct the feature information of neighboring nodes from the latent representation matrix Z, i.e., the adjacency matrix. Calculate the reconstruction error between the preset map and the feature information of neighboring nodes. After the reconstruction error is normalized, anomaly scores are obtained. Among them, Normal behavior has a low reconstruction error and a low anomaly score; abnormal behavior has a high reconstruction error and a high anomaly score. For example, when an attacker uses a `setns` call to escape container isolation, GAT will detect a significant difference between this operation and normal behavior, leading to an increased reconstruction error and thus a high anomaly score. The calculated anomaly score is sent to the adaptive response orchestrator in JSON format via an internal message queue or gRPC call. The anomaly score is a floating-point number between 0 and 1. This application solves the fundamental problem of rule-based systems by automatically learning a preset graph of normal behavior and detecting unknown attacks that deviate from the preset graph.

[0138] In one embodiment, obtaining the target behavior map based on the dynamic behavior map includes:

[0139] The target behavior map is obtained from the dynamic behavior map based on preset conditions; the preset conditions include preset periods or preset events.

[0140] Specifically, triggered by a preset period, such as every 5 seconds, or by a preset event (such as a setns call), the GNN analysis engine directly queries the dynamic data graph or graph snapshot managed by the CBG builder via API; it extracts the subgraph related to a specific analysis target, such as a single container, from the complete dynamic behavior graph, i.e., the target behavior graph.

[0141] This application will illustrate several scenarios. Scenario 1: Detecting container escape attacks exploiting unknown kernel vulnerabilities. An attacker gains a foothold within a container and, using an undisclosed (zero-day) kernel vulnerability, escapes the container's namespace isolation through a series of unconventional system call combinations (e.g., an unusual sequence of `unshare` and `setns` calls, coupled with specific file operations), attempting to execute commands on the host machine. Based on the method in this application, the eBPF collector captures this series of seemingly independent but tightly sequenced system call events, including `unshare`, `openat`, `setns`, `write`, and `execve`. CBG Construction: The CBG constructor transforms these events into a behavior graph. The graph forms an unusual path starting from a process node within the container, passing through a series of system call nodes, and ultimately connecting to files (such as ` / etc / cron.d / attack`) and new processes (such as `whoami`) under the host machine's root namespace. This path forms an edge that crosses the "container boundary," which is a key feature. GNN Analysis: When analyzing the container's subgraph, the GNN analysis engine found that its graph structure (with unusual cross-namespace connections) and node sequence deviated significantly from the baseline model learned from a large number of normal container behaviors. Therefore, the graph autoencoder could not accurately reconstruct this subgraph, resulting in an extremely high reconstruction error. Output: The GNN engine outputs a high anomaly score close to 1.0. Upon receiving this score, the response orchestrator determines that it exceeds the first preset value θhigh and immediately triggers a creu restore operation, restoring the container to its healthy state before the attacker causes persistent damage to the host machine (such as establishing a backdoor).

[0142] Scenario 2: Defending against latent encrypted resource-consuming software. A container image is implanted with a latent encrypted resource-consuming program. This program is activated within a random period after the container starts, begins performing CPU-intensive computations, and attempts to establish a network connection with an external mining pool. Based on the method of this application, the eBPF collector captures the unexpected startup (execve) of a process within the container. Subsequently, this process continuously generates a large number of computation-related system calls and issues socket and connect system calls, attempting to connect to an IP address with unknown reputation outside the organization's network policy. CBG Construction: A new process node appears in the graph, which is associated with a large amount of CPU activity and creates a network socket byte point pointing to an external IP address. GNN Analysis: The GNN model learns the behavior of normal business containers and knows that the normal mode of this container is to handle web requests, and its process behavior and network connection mode are predictable. The newly emerging anomalous resource-consuming process and its network behavior constitute an isolated branch on the graph that is completely unrelated to the normal business mode, which is a significant structural anomaly. The model therefore produces a high reconstruction error. Output: The GNN engine outputs an anomaly score in the mid-to-high range (e.g., 0.85). The response orchestrator, based on the policy, first triggers a criu dump to snapshot the container and preserve evidence, then isolates the container's network via the Kubernetes API to prevent it from communicating with the mining pool. If the score continues to rise or reaches the maximum threshold, a rollback operation can be further performed.

[0143] like Figure 6 As shown, Figure 6 This is a schematic diagram of the structure of a container self-healing security device provided in an embodiment of this application. The container self-healing security device 600 includes: a collection module 601, used to collect system behavior events during container operation and generate an event stream based on the system behavior events; the system behavior events include at least process creation, file access, and network connection; a construction module 602, used to construct a dynamic behavior graph based on the event stream; a processing module 603, used to generate an anomaly score based on the degree of deviation between the dynamic behavior graph and a preset graph; and an execution module 604, used to trigger a state recovery mechanism based on the anomaly score to roll back the container's running state.

[0144] In one embodiment, the execution module 604 is used to determine whether to perform a full rollback or a partial repair on the container based on the comparison result of the anomaly score and a preset threshold; if the anomaly score is greater than or equal to a first preset value, a full rollback is performed on the container to restore the container's running state to the previous trusted checkpoint; if the anomaly score is less than the first preset value but greater than or equal to a second preset value, a partial repair is performed on the container to isolate the abnormal process and save the container's running state.

[0145] In one embodiment, the execution module 604 is configured to mark the container's system behavior event as a low-risk event and write it to the log system if the anomaly score is less than a second preset value.

[0146] In one embodiment, the construction module 602 is used to parse the event stream, obtain the entities in the event stream and the interaction relationships between the entities; map the entities to graph nodes, map the interaction relationships between entities to graph edges; and construct a dynamic behavior graph based on the graph nodes and graph edges.

[0147] In one embodiment, the construction module 602 is used to obtain the behavior graph at the current moment based on graph nodes and graph edges; and to update the attribute information of graph nodes and graph edges based on the behavior graph at the current moment and the system behavior events at the next moment to obtain a dynamic behavior graph.

[0148] In one embodiment, the processing module 603 is used to perform feature encoding on the node attributes in the target behavior graph to obtain node features; the node attributes include at least process name and file type; based on the node features and the structural information of the target behavior graph, as well as the preset graph, an anomaly score is generated; wherein, the preset graph is the distribution of node attributes and edge relationships of the container in the normal state.

[0149] In one embodiment, the processing module 603 is used to reconstruct the feature information of neighboring nodes through a graph attention network based on the structural information and node features of the target behavior graph; calculate the reconstruction error of the dynamic behavior graph based on the preset graph and the feature information of neighboring nodes; and obtain an anomaly score based on the reconstruction error.

[0150] In one embodiment, the processing module 603 is used to obtain a target behavior map from the dynamic behavior map based on preset conditions; the preset conditions include a preset period or a preset event.

[0151] In one embodiment, the acquisition module 601 is used to obtain event context information from the kernel data structure of the container based on the event triggering within the container; the context information includes at least the process name, username, container name, call parameters, file path and network 5-tuple; after filtering or aggregating the event context information, the system behavior event is obtained.

[0152] In one embodiment, the acquisition module 601 is used to convert system behavior events into six-tuples including time; and arrange the six-tuples in chronological order to obtain an event stream; wherein the event stream is an ordered event sequence.

[0153] In one embodiment, the construction module 602 is used to assign different weights to node-level, edge-level and subgraph-level features, dynamically adjust the aggregation strategy through an attention mechanism, capture node sequences within a time window through subgraph-level attention, and construct a dynamic behavior graph based on the node sequences to identify the temporal evolution characteristics of attack behavior.

[0154] The container self-healing safety device 600 provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0155] This application provides an electronic device, including: a memory and a processor;

[0156] The memory stores the instructions that the computer executes;

[0157] The processor executes computer execution instructions stored in memory, causing the processor to perform any of the methods described above.

[0158] Figure 7 A schematic diagram of the structure of the electronic device provided in this application. Figure 7 As shown, the electronic device 700 provided in this embodiment includes at least one processor 701 and a memory 702. Optionally, the electronic device 700 further includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus 704.

[0159] In a specific implementation, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to perform the above-described method.

[0160] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0161] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0162] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0163] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0164] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0165] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0166] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0167] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0168] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0169] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0170] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0171] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0172] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0173] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A self-healing safety method for containers, characterized in that, include: Collect system behavior events during container runtime, and generate an event stream based on the system behavior events; The system behavior events include at least process creation, file access, and network connection; A dynamic behavior graph is constructed based on the event flow; Based on the dynamic behavior map, a target behavior map is obtained, and based on the degree of deviation between the target behavior map and the preset map, an anomaly score is generated; Based on the anomaly score, a state recovery mechanism is triggered to roll back the runtime state of the container.

2. The method according to claim 1, characterized in that, The step of triggering a state recovery mechanism based on the anomaly score to roll back the container's running state specifically includes: Based on the comparison result between the anomaly score and the preset threshold, it is determined whether to perform a full rollback or a partial repair on the container. The process of performing a full rollback or partial recovery on the container specifically includes: If the anomaly score is greater than or equal to the first preset value, then a full rollback is performed on the container to restore the container's running state to the previous trusted checkpoint. If the anomaly score is less than the first preset value and greater than or equal to the second preset value, then a partial recovery is performed on the container to isolate the abnormal process and save the running state of the container.

3. The method according to claim 2, characterized in that, The method further includes: If the anomaly score is less than the second preset value, the system behavior event of the container is marked as a low-risk event and written to the log system.

4. The method according to claim 1, characterized in that, The construction of a dynamic behavior graph based on the event stream includes: Parse the event stream to obtain the entities in the event stream and the interaction relationships between the entities; The entities are mapped as graph nodes, and the interaction relationships between the entities are mapped as graph edges; The dynamic behavior graph is constructed based on the graph nodes and graph edges.

5. The method according to claim 4, characterized in that, The construction of the dynamic behavior graph based on the graph nodes and graph edges specifically includes: Based on the graph nodes and graph edges, obtain the behavior graph at the current moment; Based on the behavior graph at the current moment and the system behavior events at the next moment, the attribute information of the graph nodes and the graph edges is updated to obtain a dynamic behavior graph.

6. The method according to claim 1, characterized in that, Based on the degree of deviation between the target behavior map and the preset map, an anomaly score is generated, including: The node attributes in the target behavior graph are feature-encoded to obtain node features; the node attributes include at least process name and file type. Based on the node features and the structural information of the target behavior graph, as well as the preset graph, an anomaly score is generated; The preset graph is the distribution of node attributes and edge relationships of the container in its normal state.

7. The method according to claim 6, characterized in that, The generation of anomaly scores based on the node features, the structural information of the target behavior graph, and a preset graph specifically includes: Based on the structural information of the target behavior graph and the node features, the feature information of neighboring nodes is reconstructed through a graph attention network; Based on the preset graph and the feature information of the neighboring nodes, the reconstruction error of the dynamic behavior graph is calculated; The anomaly score is obtained based on the reconstruction error.

8. The method according to claim 6, characterized in that, The step of obtaining the target behavior map based on the dynamic behavior map includes: The target behavior map is obtained from the dynamic behavior map based on preset conditions; the preset conditions include preset periods or preset events.

9. The method according to claim 1, characterized in that, The system behavior events collected during container runtime specifically include: Based on the event triggered within the container, event context information is obtained from the container's kernel data structure; the context information includes at least the process name, username, container name, call parameters, file path, and network 5-tuple; The system behavior events are obtained by filtering or aggregating the events based on the context information.

10. The method according to claim 9, characterized in that, The generation of the event stream based on the system behavior events includes: The system behavior events are transformed into six-tuples including time; The six tuples are arranged sequentially according to time to obtain the event stream; wherein, the event stream is an ordered sequence of events.

11. The method according to claim 5, characterized in that, The construction of the dynamic behavior graph based on the graph nodes and graph edges specifically includes: Different weights are assigned to node-level, edge-level, and subgraph-level features, and the aggregation strategy is dynamically adjusted through an attention mechanism. The node sequence within a time window is captured by subgraph-level attention, and the dynamic behavior graph is constructed based on the node sequence to identify the temporal evolution characteristics of attack behavior.

12. A container self-healing safety device, characterized in that, include: The acquisition module is used to acquire system behavior events during container runtime and generate an event stream based on the system behavior events; The system behavior events include at least process creation, file access, and network connection; A construction module is used to construct a dynamic behavior graph based on the event stream; The processing module is used to generate an anomaly score based on the degree of deviation between the dynamic behavior map and the preset map; The execution module is used to trigger a state recovery mechanism based on the anomaly score to roll back the running state of the container.

13. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-11.

15. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-11.

Images