Container behavior supervision method and device based on priority

Abstract

The invention relates to the technical field of container safety, and provides a priority-based container behavior supervision method and device. The method comprises the following steps: determining a mirror image priority according to a mirror image construction file; appointing a corresponding Seccomp strategy according to the mirror image priority; a mapping relation between the mirror image priority and the Seccomp strategy is established; obtaining a Seccomp strategy according to the mapping relation, and starting a container by using the Seccomp strategy; and monitoring a Seccomp event triggered by the container process, extracting a system calling behavior and performing structured recording to generate a structured log. According to the method and the device, dynamic security policy management based on the mirror image risk level is implemented on the container operation authority, and the problems of relatively low security, isolation and traceability during container operation in the prior art are solved.

Description

Technical Field

[0001] This invention relates to the field of container safety technology, and in particular to a priority-based method and apparatus for monitoring container behavior. Background Technology

[0002] Currently, the Linux kernel-based Seccomp (Secure Compute Mode) mechanism is widely used to restrict system call behavior within containers to block potential attack paths. The accuracy and flexibility of Seccomp policy configuration directly determine the security boundary of container operation and are crucial for improving the overall system's resistance to attacks.

[0003] However, current Seccomp policy management technologies primarily rely on static binding. This static mechanism has significant limitations. On one hand, Seccomp policies are disconnected from the risk levels of images and cannot be automatically adjusted based on vulnerability scan results or security labels set by developers. This can lead to some high-risk containers still using lenient policies, severely impacting system security. On the other hand, there is a lack of correlation between Seccomp policy execution and security audit logs. These logs often lack container context information (e.g., image name and version), increasing the complexity of anomaly identification for operations and maintenance personnel. When an image's risk level increases due to newly exposed vulnerabilities, existing solutions require manual intervention to modify policy associations by default. Furthermore, operations and maintenance personnel must manually associate unique identifiers in audit logs with container information. Faced with hundreds of system call records per second, it is difficult to quickly identify abnormal behavior. These shortcomings severely restrict the real-time performance and effectiveness of container security management.

[0004] Therefore, overcoming the shortcomings of the existing technology is an urgent problem to be solved in this technical field. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a priority-based container behavior supervision method and apparatus. Its purpose is to implement dynamic security policy management based on image risk level for container running permissions, so as to realize accurate monitoring and auditing of system call behavior, and solve the problems of low security, isolation and traceability of container runtime in the prior art.

[0006] The present invention adopts the following technical solution: In a first aspect, the present invention provides a priority-based container behavior supervision method, comprising: Determine the image priority based on the image build file; specify the corresponding Seccomp policy based on the image priority; establish a mapping relationship between the image priority and the Seccomp policy; Obtain the Seccomp policy based on the mapping relationship, and start the container using the Seccomp policy; Listen for Seccomp events triggered by the container process, extract system call behavior, and record it in a structured manner to generate structured logs.

[0007] Furthermore, determining the image priority based on the image build file includes: Scan the image build file or analyze the metadata tags defined by the developer for the image build file; If a security label has been explicitly declared in the image build file, then the security label will be determined as the image priority. If the security label is not explicitly declared in the image build file, the image priority is determined based on the CVSS score of the vulnerability scan.

[0008] Furthermore, if the security label is not explicitly declared in the image build file, the image priority is determined based on the CVSS score from vulnerability scanning, including: Perform a static vulnerability assessment on the image of the image build file, and determine the highest CVSS score corresponding to all vulnerabilities as the CVSS score; Security levels are determined based on the scoring rules and the CVSS score, and image priorities are determined according to the security levels.

[0009] Furthermore, the method also includes: Determine the risk level of the image, and use a sliding window to capture the current call sequence of the container for high-risk images; Identify system call sequences that pose an attack risk from the current call sequence; The metadata of the image corresponding to the identified system call sequence, the structured system call logs, the comprehensive score, and the comprehensive risk score are associated to generate a complete source map.

[0010] Furthermore, determining the risk level of the mirror image includes: The image's CVSS score, number of historical attack events, business sensitivity tags, and container resource quotas are used as the criteria layer of the analytic hierarchy process to generate subjective weights for each dimension; the subjective weights are then corrected using the entropy weight method to obtain objective weights. Calculate the final priority weight of the image: ;in, The subjective weight, The objective weight, This is the business sensitivity coefficient; The risk level of the image is classified into one of high risk, medium risk, or low risk according to the final priority weight.

[0011] Furthermore, the step of determining the system call sequence with attack risk from the current call sequence includes: Determine the cosine similarity between the current call sequence and the preset attack chain template; determine the Levenshtein edit distance between the current call sequence and the preset attack chain template; Calculate the overall score of the current call sequence. ;in, The cosine similarity is... The weights of the cosine similarity are... Edit the distance for the Levenshtein. The weights for the Levenshtein edit distance, The current call sequence length is defined as follows: when the overall score is greater than a preset malicious value, it is determined that the current call sequence poses an attack risk.

[0012] Furthermore, the method also includes: Capture the return value after a system call to determine the risk value of the return value; determine the weight of high-risk calls and use it as the base risk value; determine the cumulative risk value according to the number of times the same system call is repeated; determine the frequency risk value based on the call density per unit time. Calculate the comprehensive risk score ;in, Scores for each risk dimension, Weights for each risk dimension ,in, For the entropy of each risk dimension, , For normalized quantities, The total number of system calls. , For the first The system call in the ... Risk values ​​for each of the following risk dimensions: basic risk, cumulative risk, frequency risk, and return value risk.

[0013] Furthermore, the step of listening to the Seccomp event triggered by the container process, extracting system call behavior, and recording it in a structured manner to generate structured logs includes: Continuously monitor the operating system's Audit log source, filter out system call events triggered by Seccomp, and obtain Seccomp events; Extract the information fields of the Seccomp event; wherein, the information fields include the container identifier and the system call number; Based on the identifier, determine the container to which the Seccomp event belongs; convert the system call number into a readable name; The information fields and the Seccomp event are used to generate standardized structured log items to obtain structured logs.

[0014] Secondly, the present invention also provides a priority-based container behavior monitoring device for implementing the priority-based container behavior monitoring method described in the first aspect, the device comprising: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor for performing the priority-based container behavior supervision method described in the first aspect.

[0015] Thirdly, the present invention also provides a non-volatile computer storage medium storing computer-executable instructions that are executed by one or more processors to perform the priority-based container behavior supervision method described in the first aspect.

[0016] This invention monitors container behavior based on dynamic image priority determination. By establishing a mapping relationship, it dynamically injects specified Seccomp policies, starts the container, and monitors and records through structured logs. It provides a runtime security management mechanism for a closed-loop feedback monitoring system. Seccomp policies can be dynamically loaded and adjusted during container operation, enabling real-time perception, risk assessment, and automated management of the entire process of policy response for system call behavior. This overcomes the technical bottlenecks of rigid, disconnected, and fragmented traditional Seccomp policies, significantly improving the security, responsiveness, and management efficiency of the container environment. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly described below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0018] Figure 1 This is a flowchart illustrating a priority-based container behavior monitoring method provided in an embodiment of the present invention. Figure 2 This is a flowchart illustrating step 10 provided in an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating a specific example of a container behavior monitoring method provided in an embodiment of the present invention; Figure 4 This is a flowchart illustrating step 103 provided in an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating a specific example of a container behavior monitoring method provided in an embodiment of the present invention; Figure 6 This is a flowchart illustrating step 30 provided in an embodiment of the present invention; Figure 7 This is a schematic diagram illustrating a specific example of container behavior monitoring, log structuring, and deduplication provided in an embodiment of the present invention. Figure 8 This is a schematic diagram of a log structuring and deduplication process provided in an embodiment of the present invention; Figure 9 This is a schematic diagram illustrating a specific example of a container security policy management system architecture provided in an embodiment of the present invention; Figure 10 This is a schematic diagram of a process for identifying and processing malicious behaviors combined with legitimate system calls, provided by an embodiment of the present invention. Figure 11 This is a flowchart illustrating a specific example of identifying and processing malicious behavior combined with legitimate system calls, as provided in an embodiment of the present invention. Figure 12 This is a schematic diagram of the architecture of a priority-based container behavior monitoring device provided in an embodiment of the present invention. Detailed Implementation

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

[0020] In the description of this invention, the terms "inner", "outer", "longitudinal", "lateral", "upper", "lower", "top", "bottom", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and do not require that this invention must be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting this invention.

[0021] In this invention, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0022] In this application, unless otherwise expressly specified and limited, the term "connection" should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral part; it can be a direct connection or an indirect connection through an intermediate medium. Furthermore, the term "coupled" can refer to an electrical connection that enables signal transmission.

[0023] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0024] Example 1: Current Seccomp policy management technologies primarily rely on static binding, meaning a fixed system call whitelist is pre-defined for containers during the image building phase. For example, Chinese patent CN111651752A, "A Method for Obtaining a System Call Whitelist Required by a Container," proposes generating a call whitelist by combining static and dynamic analysis, but it doesn't address the issue of real-time policy updates at runtime. This static mechanism has significant limitations: First, the policy is disconnected from the image's risk level, failing to automatically adjust based on vulnerability scan results or security tags set by developers. This can lead to some high-risk containers still using lenient policies, as seen in Chinese patent CN114546539A, "A Method for Generating a System Call Whitelist for Interpreted Language Source Programs." Second, there's a lack of correlation between policy execution and security audit logs; logs often lack container context information (e.g., image name and version), increasing the complexity of anomaly location during operations. Third, the large number of system call records generated in high-concurrency scenarios contains numerous duplicate legitimate events; the lack of an effective deduplication mechanism leads to bloated monitoring data and low analysis efficiency.

[0025] When a container image's risk level rises due to a newly exposed vulnerability, traditional solutions require manual intervention to modify policy associations by default. At the same time, operations and maintenance personnel need to manually associate the PID and container information in the audit logs. Faced with hundreds of system call records per second, it is difficult to quickly identify abnormal behavior. These shortcomings severely restrict the real-time performance and effectiveness of container security management.

[0026] To solve the above problems, such as Figure 1 As shown, this embodiment of the invention provides a priority-based container behavior supervision method, including: Step 10: Determine the image priority based on the image build file; specify the corresponding Seccomp policy based on the image priority; establish the mapping relationship between the image priority and the Seccomp policy.

[0027] Secure Computing Mode (Seccomp) is a security feature in the Linux kernel that allows processes to enter a restricted secure mode where they can only call a set of explicitly permitted and safe system calls. A Seccomp policy is a set of security rules that specifies which system calls a process or group of processes can execute in Seccomp restricted mode, with what parameters, and the kernel's action to take if the rules are violated. A Seccomp policy file is a configuration file that specifies and serializes the Seccomp policies and stores them on disk. Seccomp policy files can be directly read and loaded by container runtimes or system tools. In one embodiment, a Seccomp policy file can be specified, establishing a relationship between the Seccomp policy file and a specific image priority.

[0028] First, by parsing the security tags in the image build file or calling vulnerability scanning tools, the image priority is determined based on the CVSS score, and a mapping relationship is established between the image and the default Seccomp policy to achieve image priority identification and policy mapping.

[0029] In one embodiment, the mapping between PID (i.e., the container's unique identifier) ​​and container is automatically generated and updated by the container runtime script run_container.py, ensuring that the monitoring script can accurately associate system call events with container identities.

[0030] Step 20: Obtain the Seccomp policy according to the mapping relationship, and start the container using the Seccomp policy.

[0031] Subsequently, during container startup, the corresponding Seccomp policy is dynamically injected based on the mapping result, and the container's PID information is recorded to achieve automatic matching of Seccomp policies and container startup.

[0032] Step 30: Listen for Seccomp events triggered by the container process, extract system call behavior and record it in a structured manner to generate structured logs.

[0033] During system operation, the system continuously monitors Seccomp events triggered by container processes, extracts system call behavior, and records it in a structured manner to achieve real-time monitoring and structured storage of system call behavior.

[0034] This invention monitors container behavior based on dynamic image priority determination. By establishing a mapping relationship, it dynamically injects specified Seccomp policies, starts the container, and monitors and records through structured logs. It provides a runtime security management mechanism for a closed-loop feedback monitoring system. Seccomp policies can be dynamically loaded and adjusted during container operation, enabling real-time perception, risk assessment, and automated management of the entire process of policy response for system call behavior. This overcomes the technical bottlenecks of rigid, disconnected, and fragmented traditional Seccomp policies, significantly improving the security, responsiveness, and management efficiency of the container environment.

[0035] To illustrate the process of mirror priority identification and policy mapping, in one embodiment, such as Figure 2 As shown, in step 10, determining the image priority based on the image build file includes: Step 101: Scan the image build file or analyze the metadata tags defined by the developer for the image build file.

[0036] like Figure 3 As shown, the system automatically identifies the security priority of each image during the container image building or deployment phase. A specific example will be provided below, and will not be elaborated further here.

[0037] Step 102: If a security label has been explicitly declared in the image build file, then the security label is determined as the image priority.

[0038] For example, prioritize reading developer-defined security tags from the image build file, such as LABELsecurity.priority="HIGH". If a security tag exists, use that tag to obtain the image priority.

[0039] Step 103: If the security label is not explicitly declared in the image build file, the image priority is determined based on the CVSS score of the vulnerability scan.

[0040] In one embodiment, if no security label is defined, the integrated vulnerability scanning module is invoked to perform a static scan of the image directory.

[0041] This invention improves the flexibility of manual intervention by allowing developers to declare custom LABEL fields when building image build files through image priority.

[0042] In one embodiment, such as Figure 4 As shown, step 103 includes: Step 1031: Perform a static vulnerability assessment on the image of the image build file and determine the highest CVSS score corresponding to all vulnerabilities as the CVSS score.

[0043] In one embodiment, such as Figure 3 As shown, the integrated vulnerability scanning module is invoked to perform a static scan on the image directory, extract the CVSS v3-based scores of all vulnerabilities, and the highest score is determined as the CVSS score of this embodiment of the invention.

[0044] Step 1032: Determine the security level according to the scoring rules and the CVSS score, and determine the image priority according to the security level.

[0045] In one embodiment, if the CVSS score is greater than or equal to the priority threshold, the security level is low; if the CVSS score is less than the priority threshold, the security level is high; the low level or the high level is determined as the mirror priority.

[0046] The priority threshold is determined by those skilled in the art based on the specific use case; in one embodiment, the priority threshold can be 7.

[0047] In one embodiment, the scoring rule can be: based on the CVSS score, a security level of "LOW" (i.e., low level) is assigned when the score is higher than 7.0, and "HIGH" (i.e., high level) otherwise. The security level, image name, and corresponding policy file path information are written to a configuration file (e.g., priorities.json) to facilitate subsequent rapid indexing and policy matching. Images with a CVSS score higher than 7.0 are classified as "LOW" by default and are forced to comply with a stricter Seccomp policy file, prohibiting or blocking sensitive calls such as clone, ptrace, and mount.

[0048] This invention provides a closed-loop risk identification system for image databases from the source to the deployment stage, supporting both static and explicit hybrid definitions to enhance the system's automatic judgment capabilities. By automatically identifying and quantifying image risk levels, it eliminates errors from manual assessment; it dynamically adapts to different image policy allocation bases, improving the degree of security automation; and it supports both explicit declarations and static analysis, enhancing system compatibility.

[0049] To illustrate the process of mirror priority identification and policy mapping, a specific example of mirror priority identification is provided below: The input directory structure requires that the image build files be organized in a directory like "inputImgTest / project name / image build files". The system will use "project name" as the prefix for the image name by default, and generate the final image identifier such as "project n:latest".

[0050] To perform mirror analysis, use a command like: "python secMainPro.py --input-dir . / inputImgTest / ".

[0051] The priority extraction process reads directly if the image build file contains the following field: LABELsecurity.priority="HIGH". Otherwise, the system calls scan.py to perform a static scan on the image build file, parses the vulnerability entries in the JSON report, and extracts the highest CVSS score.

[0052] The priority determination logic is as follows: when the CVSS score is greater than or equal to 7.0, the priority of the mirror image is determined to be "LOW"; when the CVSS score is less than 7.0, the priority is determined to be "HIGH". Note that this standard can be manually adjusted according to specific needs.

[0053] The final step is to store the results. The identified image priorities and the default policy configuration are mapped and written to a JSON file with the following structure, stored in outputs / priorities / priorities.json.

[0054] This invention implements dynamic security policy management for container runtime permissions based on image risk levels, so as to facilitate accurate monitoring and auditing of system call behavior in the future, thereby improving the security, isolation and traceability of container runtime.

[0055] To illustrate the process of automatic Seccomp policy matching and container startup, in one embodiment, such as Figure 5 As shown, step 20 includes: obtaining the default Seccomp policy according to the mapping relationship, and dynamically injecting the default Seccomp policy during container startup.

[0056] When the system runs a container, it automatically matches the corresponding Seccomp policy file based on the aforementioned priority mapping logic, thereby enabling automatic policy loading and injection.

[0057] In one embodiment, such as Figure 5 As shown, before obtaining the default Seccomp policy according to the mapping relationship and dynamically injecting the default Seccomp policy during container startup, the method further includes: when there is an explicitly specified Seccomp policy in the container startup command, starting the container according to the explicitly specified Seccomp policy.

[0058] If the "--seccomp-file" parameter is explicitly specified in the container startup command, the user-provided policy file will be used; otherwise, the policy configuration corresponding to the current image in priorities.json will be automatically searched. A container run command containing the "--security-opt seccomp=path" parameter will be constructed to ensure that the container is in a controlled system call environment when it starts.

[0059] After the container starts, information such as the container name, image name, and container process PID is automatically recorded in the containers_pids.txt file, which serves as the basic data source for the system call audit module.

[0060] The system call behavior monitoring service was restarted synchronously to ensure that the new container was included in the real-time monitoring system.

[0061] Users can customize policy files in the outputs / seccomp / path, adjust their system call whitelists, and achieve dynamic policy updates to meet the needs of different scenarios.

[0062] Below is a specific example of container startup and Seccomp policy configuration: Users can start the container using the following command and apply the Seccomp policy automatically or manually: Method 1: Automatic Strategy Matching For example, the startup command is: python run_container.py simple-high:latest --namesimple1 The process is as follows: The system queries the policy corresponding to the image "simple-high:latest" based on priorities.json; selects "seccomp-high.json"; generates the container command; after startup, the container name and PID will be written to the path "outputs / containers_pids.txt".

[0063] Method 2: Manually specify the strategy For example, the startup command is: "python run_container.py simple-high:latest --namesimple2 --seccomp-file seccomp-low.json".

[0064] The system will prioritize using seccomp-low.json to override the automatic policy.

[0065] Regardless of the method used, once the container has started, the system will call monitor_syscalls.py to start the auditing task.

[0066] This invention enables quantifiable dynamic control over container runtime permissions, reducing human configuration errors and allowing for plug-and-play policies. It achieves automated dynamic control of container runtime permissions, significantly reducing configuration risks; policies are strongly bound to images, ensuring stricter security control for high-risk images; and it supports user policy overriding mechanisms, enhancing policy flexibility.

[0067] To illustrate the process of real-time monitoring and structured storage of system call behavior, in one embodiment, such as Figure 6 As shown, step 30 includes: Step 301: Continuously monitor the operating system's Audit log source, filter out system call events triggered by Seccomp, and obtain Seccomp events.

[0068] In one embodiment, such as Figure 7 As shown, the first step is to perform real-time monitoring and parsing of Seccomp system call behavior. During the container runtime phase, the system starts the Seccomp event monitoring module, which continuously listens for system call behavior triggered by the container process through the Auditd log interface, and performs real-time parsing and archiving: the audit event listener reads information from " / var / log / audit / audit.log" in real time.

[0069] Step 302: Extract the information fields of the Seccomp event; wherein the information fields include the container identifier and the system call number.

[0070] The information fields are determined by those skilled in the art based on the specific use case. In one embodiment, they may include PID, syscall number, and timestamp. System call log entries containing Seccomp type are parsed to extract key fields such as PID, syscall number, and container timestamp.

[0071] Step 303: Determine the container to which the Seccomp event belongs based on the identifier; convert the system call number into a readable name.

[0072] For example, querying containers_pids.txt allows matching container names and image names based on their PIDs, enabling traceable binding of container identities. System call numbers are mapped to readable names using an internal table.

[0073] Step 304: Use the information field and the Seccomp event to generate standardized structured log items to obtain structured logs.

[0074] For example, construct a standardized behavior log recording object with fields including container name, image name, PID, system call name, timestamp, etc.

[0075] This invention achieves container visibility of system call events through container-level process identifier binding and event parsing, supporting subsequent threat analysis and forensic tracing.

[0076] Below is a specific example of Seccomp system call event monitoring: After the container starts running, the system automatically starts the system call monitoring module, which is responsible for collecting and processing Seccomp events triggered by the container process in real time.

[0077] Key functions and parameters include: log source / var / log / audit / audit.log, container mapping file outputs / containers_pids.txt, and output file path: outputs / syscalls_log.json.

[0078] Event handling process: The system scans new audit logs every second; matches events of type "type=SECCOMP" and extracts the PID and syscall; finds the container name and image corresponding to the PID from the container mapping file; maps the syscall number to the system call name; and constructs structured data.

[0079] Event deduplication rules: unique key (PID, syscall name); if the same event occurs repeatedly, skip the record; ensure that the structured log is clean, readable, and traceable.

[0080] The embodiments of the present invention realize container-level system call behavior tracing, improve runtime observability, and can provide real-time behavior data for auditing systems or security platforms.

[0081] Furthermore, existing technologies generate a large number of duplicate legitimate events in the system call records generated under high-concurrency scenarios. The lack of an effective deduplication mechanism leads to an explosion of monitoring data and low analysis efficiency.

[0082] To address this problem, embodiments of the present invention perform log structuring and duplicate event deduplication; in one embodiment, such as Figure 8 As shown, after step 30, the method further includes: Step 401: Detect whether a new structured log already exists based on the fixed pattern.

[0083] like Figure 7As shown, in one embodiment, Seccomp events are first deduplicated based on the container's identifier and system call number; for example, by constructing a combined unique identifier (such as combining the PID and syscall name), it is determined whether the current record already exists in the log. The system constructs a combination key "(PID, syscall_name)" for each event to be written.

[0084] Step 402: If a new structured log already exists, discard the new structured log.

[0085] For example, if the key combination already exists in an existing log record, the write will be automatically skipped to avoid duplication.

[0086] Step 403: If the new structured log does not exist, then write the new structured log to the log file.

[0087] For example, if the new structured log is a new event, it is appended to the structured log. In one embodiment, it is appended to the structured log file syscalls_log.json, with the log format being standard JSON, adapted to the security audit platform.

[0088] This invention avoids redundant and bloated system call logs through structured storage and event deduplication. The system supports automatic log rotation and periodic archiving, facilitating long-term recording with low storage overhead. It significantly reduces log redundancy, improves system resource utilization, and ensures the controllability and long-term nature of log collection. It avoids redundant log recording, reducing storage and processing burdens; it adapts to high-concurrency container deployment environments, improving overall system performance. Since the system call log deduplication mechanism can use "(PID, syscall name)" as a unique key, it effectively reduces log redundancy and improves audit processing efficiency during system runtime.

[0089] like Figure 9 As shown, in one embodiment, this invention not only constructs a data loop between functional modules using the above method, but also automates the process from image security level identification to system call behavior auditing at the deployment architecture level. This system is particularly suitable for scenarios with high security isolation requirements, such as government and enterprise private cloud platforms, critical infrastructure edge devices, trusted upgrade systems, and industrial control container environments.

[0090] In this structural system, the linkage process of each module is as follows: 1. A pre-configured image priority module serves as a risk entry analyzer. This module not only functions during the image building phase but also supports batch scanning of the deployed image directory. It supports parsing various input path structures and allows developers to customize priority rules via a script interface. Additionally, this module supports vulnerability scanning, automatically parsing JSON reports, extracting high-risk vulnerability scores, and automatically binding images to priority tags.

[0091] In addition, after determining the priority, the module generates a structure containing the following key fields: image: Image name; timestamp: timestamp; priority: Priority label (e.g., low risk or high risk); seccomp_policy: The matching Seccomp policy.

[0092] This structure is ultimately written to the priorities.json file and permanently stored in the data persistence layer for reference by subsequent modules.

[0093] 2. The Seccomp policy dynamic configuration module serves as the central control point for access control. During the container startup phase, this embodiment of the invention automatically pushes Seccomp policies of varying strictness based on image priority. This mechanism ensures that: high-risk images automatically adopt the strictest policies, such as prohibiting sensitive calls like clone, ptrace, and mount; low-risk images can adopt more lenient policies, taking functionality into consideration.

[0094] If the developer explicitly specifies the policy path (through startup script parameters), the system will prioritize using the user-specified policy, ensuring policy controllability and traceable behavior.

[0095] In addition, this module uses the information persistently stored in the priorityities.json file by the pre-configured image priority module (the user uses the default policy and does not specify a specific policy file) to start the corresponding container. After the container starts successfully, it will automatically write information such as container PID, container name, and image name to containers_pids.txt, providing container identity resolution support for the behavior monitoring module.

[0096] 3. The security monitoring and feedback system serves as the core of behavior monitoring. This module parses Audit log files and matches container identities based on PIDs to achieve accurate tracking of system call behavior of running containers.

[0097] Key features include: Retrieve new audit.log entries in real time; Extract the syscall number and convert it to a name (e.g., SYS_openat); Query the PID mapping file to match container name and image name; Generate structured event logs in a uniform format (JSON format); Perform deduplication using the "(PID, syscall)" key combination to prevent duplicate records; Furthermore, embodiments of the present invention support rule matching and risk labeling of behavioral events, such as marking unknown container behavioral events as "unknown" and isolating and recording them.

[0098] In addition, the module stores the filtered structured logs to the file syscalls_log.json for researchers to audit and track anomalies.

[0099] 4. The data persistence layer serves as a system state snapshot repository. The data layer supports multiple data storage structures, defaulting to either local JSON files or a TXT file system structure; the TXT file structure is suitable for lightweight deployment scenarios. This layer's data supports the following uses: Prioritize caching for acceleration; Container identity resolution and mapping; Behavioral auditing and compliance review; Vulnerability trends and log visualization analysis.

[0100] Meanwhile, all data is labeled with a standard timestamp field, which can be used for cross-stage behavior tracing and historical event correlation.

[0101] The overall system operation process embodies a closed-loop security strategy of "pre-event identification + in-event control + post-event traceability": Before the image is started, its risk level and matching strategy are determined through static analysis. During startup, strategies are dynamically injected and identity information is established; Continuously collect system call behavior during operation and perform multi-dimensional structuring; Audit logs are processed in real time and support the tracking of high-risk behaviors and policy rollback.

[0102] Through the above architecture design, this invention achieves container-level fine-grained permission management, runtime behavior tracking, event risk awareness, and compliant log archiving, featuring high automation, low invasiveness, strong security, and good scalability.

[0103] This invention also provides a Seccomp policy template: When writing custom Seccomp policy files, users should follow these rules: set the global default behavior to SCMP_ACT_ERRNO; set the allowed system call behavior to SCMP_ACT_LOG. Specifically, set `defaultAction` to intercept undefined system calls; `action` to log allowed system calls; and `archMap` to automatically select the supported architecture based on the running architecture.

[0104] Building upon this foundation, this invention also provides a novel boundary and enhancement support scheme: the system supports concurrent monitoring of multiple containers, tracking the PIDs and behavior logs corresponding to multiple containers; when a container exits, the system automatically removes the relevant entries from the PID mapping file; policy files support hot updates, allowing users to refresh policies without restarting containers (supported in future versions); logs can be pushed to Kafka, ELK (i.e., Elasticsearch, Logstash, and Kibana) or security platforms via plugins for anomaly detection and security auditing; and policies can be automatically bound to roles or image repositories to achieve security policy distribution under the continuous integration / continuous delivery (CI / CD) chain.

[0105] This invention implements a complete closed-loop management process, encompassing image security level identification, automatic security policy matching, container runtime system call behavior auditing, and structured log storage. The modules are logically clear, data sharing is efficient, and configuration is flexible, resulting in excellent deployability in practical engineering projects.

[0106] It should be noted that the embodiments of the present invention use Python scripts to implement each functional module, but the priority-based container behavior supervision method of the present invention is not limited to a specific implementation language or running platform. Any system that uses a similar method to implement the above functions should be regarded as an equivalent technical solution of the present invention.

[0107] The embodiments of the present invention have the advantages of automated policies, auditable behavior, and controllable permissions, which significantly improve the security and traceability of container runtime and are suitable for runtime protection and security compliance auditing scenarios in multi-container concurrent deployment and cloud-native environments.

[0108] This invention constructs a complete access control framework for container runtime environments by introducing an automatic security level identification mechanism at the image level, a dynamic policy injection mechanism based on policy mapping, and a structured storage and deduplication mechanism for Seccomp behavior logs. This method combines automation, adaptability, low invasiveness, and strong auditing capabilities, effectively improving container runtime security, behavior visualization capabilities, and attack / defense forensics capabilities, and has broad practical value and promising prospects for industrial application.

[0109] Example 2: This embodiment is a preferred embodiment of the present invention.

[0110] In existing technologies, traditional container behavior monitoring solutions based on Seccomp whitelists only verify the legitimacy of individual system calls, failing to identify malicious behavior formed by attackers using combinations of legitimate system calls. Specifically, a legitimate system call combination might involve an attacker first reading a malicious code file using the `open` system call, then loading it into executable memory using the `mmap` system call, subsequently injecting it into the target process using the `ptrace` system call, and finally connecting to the network via the `socket` system call. Traditional whitelisting solutions allow the `open` system call in isolation but fail to analyze its correlation with subsequent high-risk call sequences. Since allocating executable memory using mmap is legal and is often used for Just-In-Time (JIT) compilation; debugging or injecting other processes using ptrace is legal and is often used for development debugging; connecting to the network using sockets is also legal and is used for normal communication; system calls open, mmap, ptrace, or socket are all in the Seccomp whitelist, meaning each individual action is legal, and the system considers it safe as long as the container executes a system call in the Seccomp whitelist, or simply logs a message. Therefore, existing technical solutions cannot identify the attack intent and are vulnerable to this type of attack.

[0111] Meanwhile, the large volume of logs in the Seccomp whitelist and the loss of the crucial characteristic of order after deduplication make it impossible to locate and trace this type of attack. There are also problems such as poor policy synchronization consistency, incomplete call capture dimensions, and weak adaptability of sequence analysis, which lead to failure in attack intent identification, low supervision efficiency, and poor practicality.

[0112] To solve the above problems, such as Figure 10 As shown, the method further includes: Step 501: Determine the risk level of the image to capture the current call sequence of the container using a sliding window for high-risk images.

[0113] In Embodiment 1 of this invention, the security level of each image is divided into two image priorities: high and low, so that the Seccomp strategy can be specified for the corresponding image in a differentiated manner according to the image priority. Here, this embodiment uses the CVSS score obtained when calculating the image priority to further evaluate the static risk of each image and divide it into three levels: high risk, medium risk and low risk. For high-risk images, a sliding window is used to capture and analyze the system call sequence.

[0114] Step 502: Determine the system call sequence with attack risk from the current call sequence.

[0115] Step 503: Associate the metadata of the image corresponding to the determined system call sequence, the structured system call log, the comprehensive score, and the comprehensive risk score to generate a complete source map.

[0116] A complete source map facilitates the identification of the attack's origin and propagation path, enabling full-chain tracing of malicious behavior. A specific example will be given below, and will not be elaborated upon here.

[0117] like Figure 11 As shown, this embodiment solves the core problem that existing technical solutions cannot identify "malicious behavior combining legitimate system calls" through a six-stage, closed-loop design of "image grading - policy synchronization - call capture - sequence analysis - risk scoring - graded interception". The details are as follows: Phase 1: Image Priority Pre-evaluation + Container Metadata Mapping Existing technical solutions lack multi-dimensional risk priority classification for images, and container identifiers and metadata queries are not pre-bound, resulting in inefficient queries during subsequent call capture and an inability to specifically target and detect malicious call combinations of high-risk images.

[0118] To address this issue, this embodiment uses the Analytic Hierarchy Process (AHP)-entropy weight method for multi-dimensional priority assessment. In one embodiment, step 501, determining the risk level of the image includes: Step 601: Use the CVSS score of the image, the number of historical attack events, the business sensitivity label, and the container resource quota as the criteria layer of the analytic hierarchy process to generate subjective weights for each dimension; correct the subjective weights based on the entropy weight method to obtain objective weights.

[0119] There are four dimensions: CVSS score, number of historical attack events, business sensitivity label, and container resource quota. The container resource quota can be the percentage of Central Processing Unit (CPU) or memory usage. The methods for obtaining the number of historical attack events, business sensitivity label (and business sensitivity coefficient in step 602), and container resource quota, the use of the analytic hierarchy process (AHP) to generate the subjective weights for each dimension, and the specific method for correcting the subjective weights based on entropy weighting are all determined by those skilled in the art based on the specific application scenario and are not limited here. In one embodiment, these four dimensions are used as a criterion layer. The AHP is used for analysis, and the target layer can be defined as the image security priority, and the solution layer as a specific image list. The final weight results are calculated (e.g., the subjective weight of the CVSS score dimension is 0.40, the subjective weight of the number of historical attack events dimension is 0.30, the subjective weight of the business sensitivity label dimension is 0.20, and the subjective weight of the container resource quota dimension is 0.10), and these are used as subjective weights. In one embodiment, the higher the entropy value of each dimension, the greater its objective weight.

[0120] Step 602: Calculate the final priority weight of the image: ;in, The subjective weight, The objective weight, This represents the business sensitivity coefficient.

[0121] Step 603: Classify the risk level of the image into one of high risk, medium risk or low risk according to the final priority weight.

[0122] Based on the final priority weight, the images are divided into three risk levels: high, medium, and low. For example, a final priority weight greater than 7.0 is considered high risk, less than 1.0 is considered low risk, and the rest are considered medium risk. High-risk images will subsequently be subject to stricter sequence detection rules.

[0123] In Embodiment 1 of this invention, step 303, "container identifier matching," is moved to metadata binding before image startup, while the dimensions of priority evaluation are expanded. This multi-dimensional priority evaluation enables differentiated risk grading of images, focusing on stricter detection rules for high-risk images, improving the accuracy of malicious call combination identification, and achieving differentiated risk grading of images—high-risk images are subject to key monitoring, and their system call sequences can be accurately analyzed in subsequent stages, thereby solving the problem of identifying "legitimate call combinations of malicious behavior" (focusing on high-risk objects, reducing invalid detection, and improving the efficiency of malicious combination identification).

[0124] Then, consistent hash binding of container metadata is performed. That is, the container identifier corresponding to the image is mapped to the cluster metadata node through consistent hashing, completing the pre-binding between the image and the metadata node. Consistent hash binding allows subsequent call captures to quickly locate the metadata node through the container identifier and query context information such as image priority and business tags, improving query efficiency by 80%.

[0125] Phase 2: Dynamic Strategy Injection + Distributed Version Synchronization Traditional single-node strategy updates pose consistency risks, and the lack of a canary rollout mechanism for strategy switching can easily lead to business fluctuations, making it impossible to smoothly deploy detection strategies against malicious call combinations.

[0126] In one embodiment, to address this issue, this embodiment uses Raft protocol-based policy version control synchronization. Specifically: a distributed policy version control library is constructed to replace the original single-node inotify listening, ensuring strong consistency of policy files through the Raft protocol; container nodes subscribe to Raft cluster log commit events via long connections to obtain policy updates (including malicious call combination detection rules) in real time. A traffic hash sharding canary deployment algorithm is adopted, hashing the container's system call traffic according to "PID + timestamp," mapping 5% of the traffic to the new policy (including malicious call sequence detection rules), while the remainder retains the old policy. A sliding window is used to count the anomaly rate of the canary traffic; when the anomaly rate is less than 0.1%, a full switch to the new policy is automatically implemented.

[0127] The Raft protocol ensures strong consistency of policy updates in a distributed environment, preventing policy failures due to single-node failures and guaranteeing comprehensive coverage of malicious call combination detection rules. The canary deployment mechanism avoids policy switching affecting all services, keeping the anomaly rate below 0.1% and ensuring a smooth rollout of new detection rules. This stage ultimately yields the "synchronized policy version" and the "new policy that has passed canary verification," which will be used in subsequent stages for system call capture and filtering (stage 3) and sequence analysis (stage 4), capturing target system calls and setting detection thresholds according to the rules defined in the policy.

[0128] Phase 3: Multi-dimensional capture of system calls + dual-probe event analysis Existing call capture technologies only obtain data from a single dimension, have low efficiency in call number matching, and generate large log volumes, failing to provide complete parameter, return value, and structured data support for malicious call sequence analysis.

[0129] To address this issue, this embodiment utilizes a dual-probe capture system based on the Extended Berkeley Packet Filter (eBPF) with both a kernel probe (kprobe) and a kernel return probe (kretprobe). In one embodiment, kprobe is used to capture parameters before the system call (e.g., the path of the open system call), and kretprobe is used to capture the return value after the call (e.g., the file descriptor of the open system call).

[0130] By using key-value pairs (i.e., PID + call sequence number) from the Berkeley Packet Filter Map (BPFmap), event data from previous and subsequent probes are associated to form complete call chain data.

[0131] In addition, Protocol Buffers (Protobuf) structured serialization and multi-architecture prefix tree matching of call numbers are performed. Using Protobuf to serialize call data (replacing the original JSON logs) improves compression efficiency by 60%; a prefix tree for multi-architecture (e.g., x86_64 or ARM64) system call numbers is constructed to achieve call number to name mapping. Matching (where L is the total number of architecture calls).

[0132] The dual probes capture complete data of "parameters before the call + return value after the call", with the return value providing a direct data source for the risk dimension scoring of subsequent return values.

[0133] Structured serialization reduces log volume, and prefix tree matching improves call number parsing efficiency, providing an efficient and complete data source for call sequence analysis in Phase 4 below. This phase ultimately yields "structured call data (including parameters, return values, and call names)," which serves as the core data input for the call sequence in Phase 4.

[0134] Phase 4: Time-series sliding window analysis + dynamic window adaptation Existing technical solutions lack a dynamic window adjustment mechanism, have poor adaptability to containers with different call frequencies, and a single matching algorithm cannot identify mutated malicious combinations of "inserted irrelevant system calls".

[0135] To address this issue, in one embodiment, a dynamic window adjustment scheme driven by Exponentially Weighted Moving Average (EWMA) is employed: The formula for calculating the total system call frequency of a single container per unit time using EWMA is: This formula calculates the total frequency of system calls for a single container per unit time, where, For smoothing coefficients, For the container in System call smoothing frequency at any given time For the container in The instantaneous system call frequency at any given moment.

[0136] Two sliding windows are dynamically adjusted: Window_T (time sliding window, unit: seconds) and Window_N (number sliding window, unit: number of calls). Window_T controls the time span of the call sequence, and Window_N controls the length of the call sequence. The adjustment logic is: the higher the call frequency, the smaller Window_T (to quickly capture high-frequency sequences) and the larger Window_N (to avoid missing critical steps), and vice versa, adapting to the call characteristics of different containers. The sliding window is used to constrain the range of the call sequence, ensuring that the analysis focuses on continuous and / or related call behaviors, rather than isolated system calls.

[0137] It should be noted that the current call sequence and system call sequence in this embodiment are sets of system calls initiated by a single container in chronological order within a sliding window (i.e., under Window_T or Window_N constraints). For example, a purely malicious combination of system call sequences is "mmap→ptrace→socket", and a mutated combination of system call sequences is "mmap→read→write→ptrace→socket". The current call sequence is formed by aggregating the "structured call data (including parameters, return values, and call names)" from stage 3 by sorting it according to "PID + timestamp". The capture scenario is as follows: when a container initiates a system call, the dual probes in stage 3 capture the data, which, after serialization and matching, is filtered by the sliding window to select the call set that "meets the time / quantity constraints", thus forming the current call sequence.

[0138] In one embodiment, composite pattern matching is also performed based on "cosine similarity + edit distance". To illustrate the process of calculating the comprehensive score, step 502 includes: Step 701: Determine the cosine similarity between the current call sequence and the preset attack chain template; determine the Levenshtein edit distance between the current call sequence and the preset attack chain template.

[0139] First, the cosine similarity between the current call sequence and the preset attack chain template is calculated to match complete attack chains; then, the Levenshtein edit distance is calculated to match mutated attack chains with inserted irrelevant calls. The preset attack chain template is determined by those skilled in the art based on the specific use case.

[0140] Step 702: Calculate the overall score of the current call sequence. ;in, The cosine similarity is... The weights of the cosine similarity are... Edit the distance for the Levenshtein. The weights for the Levenshtein edit distance, The current call sequence length is defined as follows: when the overall score is greater than a preset malicious value, it is determined that the current call sequence poses an attack risk.

[0141] in, and The preset malicious value is determined by those skilled in the art based on the specific use case. In one embodiment, It can be 0.7. The threshold can be 0.3: The preset malicious value can be 0.75. When the overall score is greater than the preset malicious value, the current call sequence is marked as "the call sequence has a risk of malicious behavior", indicating that "this call sequence has a high risk of attack behavior" (i.e., malicious behavior formed by a combination of legitimate system calls).

[0142] The dynamic window adapts to the call frequency of different containers, avoiding the omission of high-frequency container sequences and the misjudgment of low-frequency containers; the composite pattern matching simultaneously identifies complete attack chains and variant attack chains, solving the core problem that existing technical solutions cannot identify malicious behavior in combination of legitimate calls.

[0143] It is worth noting that the “high risk of call sequence” here is different from the “high risk of image” in Phase 1: the former is a dynamic risk assessment of container runtime behavior, while the latter is a static attribute rating of the image. The combination of the two achieves dual verification of “static rating + dynamic behavior”.

[0144] Phase 5: Multi-dimensional risk scoring + dynamic dimension weighting Existing risk scoring technologies rely on fixed dimensions and coefficients, which cannot adapt to changes in risk weights in different scenarios, and do not consider the risks brought by return values, resulting in low scoring accuracy.

[0145] To address this issue, in one embodiment, the dimension of return value risk is further expanded to calculate a comprehensive risk score. Specifically, the method further includes: Step 801: Capture the return value after the system call to determine the return value risk value; determine the weight of high-risk calls and use it as the base risk value; determine the cumulative risk value according to the number of times the same system call is repeated; determine the frequency risk value based on the call density per unit time.

[0146] The weights for each risk dimension are dynamic weights of the four types of risks in system calls (i.e., basic risk, cumulative risk, frequency risk, and return value risk), calculated using the entropy weight method. The specific methods for determining the return value risk value, basic risk value, cumulative risk value, and frequency risk value are determined by those skilled in the art based on the specific use case.

[0147] This embodiment adds a new Risk_Ret dimension: the return value risk value is used to measure the risk of the system call execution result (e.g., open returns -1 to indicate call failure), and a risk score is assigned to the failed return value (e.g., the return value risk value is +1 upon failure). This dimension is used to quantify the risk of the call execution result. Specifically, the return value after the system call corresponding to the system call sequence is captured by the eBPF kretprobe probe in phase 3. The return value, such as the file descriptor of open, is used to calculate the return value risk value.

[0148] It is worth noting that the risk value returned is inconsistent with the previous risk; Phase 1 is the mirrored static risk, Phase 4 is the malicious risk of the call sequence, and this is the risk of the call execution result. The three together constitute the multi-dimensional risk score of Phase 5, realizing the triple verification of "static attributes + dynamic behavior + execution result".

[0149] Step 802: Calculate the comprehensive risk score ;in, Scores for each risk dimension, Weights for each risk dimension ,in, For the entropy of each risk dimension, , For normalized quantities, The total number of system calls. , For the first The system call in the ... Risk values ​​for each of the following risk dimensions: basic risk, cumulative risk, frequency risk, and return value risk.

[0150] This embodiment replaces the existing technology that uses fixed coefficients, dynamically calculating the weights of each dimension using the entropy weight method. The dynamic dimension weights adapt to the calling characteristics of different scenarios, and the return value dimension supplements the risk of the execution result, making the scoring more accurate. Through three steps—normalization, dimension entropy, and weight calculation—it dynamically adapts to the risk characteristics of different scenarios, improving the accuracy of the scoring; the final result... The comprehensive risk score, together with the comprehensive score from Phase 4, constitutes the basis for determining malicious behavior, improving the accuracy of risk classification. The goal of this phase is to achieve dynamic adaptation and precise quantification of risk scoring, providing decision support for phase 6 graded interception.

[0151] Phase 6: Tiered Interception Response Existing technical solutions only generate logs, lack a complete source tracing chain, and have a single interception action, making it impossible to take differentiated measures for malicious behaviors with different risk levels, resulting in difficulties in attack source tracing and a high risk of escape.

[0152] To address this issue, in one embodiment, the OpenTelemetry driver performs source tracing link generation: In step 502, after the interception event is triggered (here, the event refers to the "high-risk call sequence event" identified in stage 4, i.e., an alarm triggered by a system call sequence that matches the characteristics of malicious combinations), in step 503, multi-stage data is associated through OpenTelemetry's TraceID: the image metadata of stage 1, the call sequence and parameters of stage 3, the Score of stage 4, and the data of stage 5. Generate a complete traceability graph containing "image → policy → call → risk → interception" (logs refer to the Protobuf format system call logs after phase 3 structured processing). OpenTelemetry is a cloud-native observability framework, and OpenTelemetry's TraceID is a globally unique identifier.

[0153] In one embodiment, a tiered response can be implemented to achieve dynamic action selection: system call sequences with a cosine similarity greater than or equal to 0.9 are identified as critical risk states. For system call sequences in critical risk states, the SCMP_ACT_TRACE action is applied, suspending the process and attaching for debugging using the GNU Debugger (GDB), dumping memory data in real time. System call sequences with a comprehensive score greater than or equal to 0.75 and a comprehensive risk score greater than or equal to 8 are identified as high risk states. For system call sequences in high risk states, the SCMP_ACT_KILL_PROCESS action is applied, terminating the entire process group to prevent child process escape. The comprehensive risk score dynamically weighted in stage 5 and the comprehensive score in stage 4 are used together as the decision-making basis for tiered interception. This tiered interception response ensures rapid blocking of high-risk malicious behavior while providing debugging and analysis space for critical risks, balancing security and observability.

[0154] It should be noted that in step 301 of Embodiment 1 of this invention, the operating system's Audit log source is monitored, and system call events triggered by Seccomp are filtered out to obtain Seccomp events; however, the events in this embodiment refer to "high-risk call sequence events identified in Phase 4" (i.e., alarms triggered by system call sequences that conform to malicious combination characteristics), rather than simple Seccomp events. The logs in this embodiment refer to "Protobuf format system call logs after phase 3 structured processing," rather than the Audit logs or JSON logs in step 301. The system call logs contain complete data such as call parameters, return values, and call names, used for generating the tracing chain; in this embodiment, after the event is triggered, a complete tracing graph is formed by associating logs, image metadata, risk scores, and other data through TraceID.

[0155] This embodiment focuses on high-risk images through multi-dimensional priority assessment, reducing invalid detection overhead; it adopts distributed strategy synchronization to ensure the consistency and smooth deployment of malicious call detection rules; it uses dual probes to capture and structured processing to provide complete and efficient call data; it uses "dynamic window + composite pattern matching" to accurately identify complete and variant malicious call combinations; it further improves the accuracy of risk judgment through dynamic weighted multi-dimensional scoring; and finally achieves "tiered interception + full-link tracing", thereby realizing a complete closed loop of "detection-judgment-handling-tracing", improving the accuracy of malicious call combination identification by more than 95%, reducing log volume by 60%, and ensuring that policy updates do not cause business jitter, making it highly practical.

[0156] Example 3: like Figure 12 The diagram shown is an architectural schematic of a priority-based container behavior monitoring device according to an embodiment of the present invention. This priority-based container behavior monitoring device includes one or more processors 21 and a memory 22. Figure 12 Take a processor 21 as an example.

[0157] Processor 21 and memory 22 can be connected via a bus or other means. Figure 12 Taking the example of a connection between China and Israel via a bus.

[0158] Memory 22, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs and non-volatile computer-executable programs, such as the priority-based container behavior supervision method in Embodiment 1. Processor 21 executes the priority-based container behavior supervision method by running the non-volatile software programs and instructions stored in memory 22.

[0159] Memory 22 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 22 may optionally include memory remotely located relative to processor 21, which can be connected to processor 21 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0160] The program instructions / modules are stored in the memory 22. When executed by one or more processors 21, they execute the priority-based container behavior supervision method in Embodiment 1 above, for example, executing each step of the priority-based container behavior supervision method described above.

[0161] It is worth noting that the information interaction and execution process between the modules and units in the above-mentioned device and system are based on the same concept as the processing method embodiment of the present invention. For details, please refer to the description in the method embodiment of the present invention, and will not be repeated here.

[0162] Those skilled in the art will understand that all or part of the steps in the various methods of the embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc.

[0163] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A priority-based container behavior supervision method, characterized in that, include: Determine image priority based on image build files; Specify the corresponding Seccomp policy based on the image priority; Establish a mapping relationship between the image priority and the Seccomp policy; Obtain the Seccomp policy based on the mapping relationship, and start the container using the Seccomp policy; Listen for Seccomp events triggered by the container process, extract system call behavior, and record it in a structured manner to generate structured logs.

2. The priority-based container behavior supervision method according to claim 1, characterized in that, The method includes: Scan the image build file or analyze the metadata tags defined by the developer for the image build file; If a security label has been explicitly declared in the image build file, then the security label will be determined as the image priority. If the security label is not explicitly declared in the image build file, the image priority is determined based on the CVSS score of the vulnerability scan.

3. The priority-based container behavior supervision method according to claim 2, characterized in that, The method includes: Perform a static vulnerability assessment on the image of the image build file, and determine the highest CVSS score corresponding to all vulnerabilities as the CVSS score; Security levels are determined based on the scoring rules and the CVSS score, and image priorities are determined according to the security levels.

4. The priority-based container behavior supervision method according to claim 1, characterized in that, The method further includes: Determine the risk level of the image, and use a sliding window to capture the current call sequence of the container for high-risk images; Identify system call sequences that pose an attack risk from the current call sequence; The metadata of the image corresponding to the identified system call sequence, the structured system call logs, the comprehensive score, and the comprehensive risk score are associated to generate a complete source map.

5. The priority-based container behavior supervision method according to claim 4, characterized in that, The determination of the risk level of the mirror includes: The image's CVSS score, number of historical attack events, business sensitivity tags, and container resource quotas are used as the criteria layer of the analytic hierarchy process to generate subjective weights for each dimension; the subjective weights are then corrected using the entropy weight method to obtain objective weights. Calculate the final priority weight of the image: ;in, The subjective weight, The objective weight, This is the business sensitivity coefficient; The risk level of the image is classified into one of high risk, medium risk, or low risk according to the final priority weight.

6. The priority-based container behavior supervision method according to claim 4, characterized in that, The system call sequences identified as having an attack risk from the current call sequence include: Determine the cosine similarity between the current call sequence and the preset attack chain template; determine the Levenshtein edit distance between the current call sequence and the preset attack chain template; Calculate the overall score of the current call sequence. ;in, The cosine similarity is... The weights of the cosine similarity are... Edit the distance for the Levenshtein. The weights for the Levenshtein edit distance, The current call sequence length is defined as follows: when the overall score is greater than a preset malicious value, it is determined that the current call sequence poses an attack risk.

7. The priority-based container behavior supervision method according to claim 4, characterized in that, The method further includes: Capture the return value after a system call to determine the risk value of the return value; determine the weight of high-risk calls and use it as the base risk value; determine the cumulative risk value according to the number of times the same system call is repeated; determine the frequency risk value based on the call density per unit time. Calculate the comprehensive risk score ;in, Scores for each risk dimension, Weights for each risk dimension ,in, For the entropy of each risk dimension, , For normalized quantities, The total number of system calls. , For the first The system call in the ... Risk values ​​for each of the following risk dimensions: basic risk, cumulative risk, frequency risk, and return value risk.

8. The priority-based container behavior supervision method according to any one of claims 1-6, characterized in that, The method includes: Continuously monitor the operating system's Audit log source, filter out system call events triggered by Seccomp, and obtain Seccomp events; Extract the information fields of the Seccomp event; wherein, the information fields include the container identifier and the system call number; Based on the identifier, determine the container to which the Seccomp event belongs; convert the system call number into a readable name; The information fields and the Seccomp event are used to generate standardized structured log items to obtain structured logs.

9. A non-volatile computer storage medium, characterized in that, The computer storage medium stores computer-executable instructions, which are executed by one or more processors to perform the priority-based container behavior supervision method according to any one of claims 1-8.

10. A priority-based container behavior monitoring device, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the processor for performing the priority-based container behavior supervision method according to any one of claims 1-8.

Images