Security detection method and device for container mirror image

Abstract

The embodiment of the invention relates to a safety detection method and device for a container mirror image. A to-be-detected mirror image comprises a container layer, a virtualization layer and a code implementation layer. The method comprises the following steps: performing first security detection on a container layer to generate a first detection result; the first security detection comprises first dynamic detection aiming at the container running condition in the container layer and first anti-attack test aiming at the running container; performing second security detection on the virtualization layer to generate a second detection result; the second security detection comprises the steps of obtaining call chain information of DMA operation in a virtualization management program of a virtualization layer, generating an initial seed according to the call chain information, and performing fuzzy testing on the virtualization management program based on a test case for performing mutation operation on the initial seed; performing third security detection on the code implementation layer to generate a third detection result; the third security detection comprises second dynamic detection for vulnerabilities during code operation and a second anti-attack test for code operation.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of information security, and more particularly to methods and apparatus for security detection of container images. Background Technology

[0002] A container is an operating system-level virtualization technology that utilizes the host kernel to package applications and their dependencies into isolated execution environments through namespaces and cgroups. With the rapid development of container technology, hybrid architecture containers that combine the lightweight nature of containers with the strong isolation of virtual machines, such as Kata containers, are becoming the mainstream choice for many applications.

[0003] With the increasing popularity of hybrid container architectures, their security faces numerous challenges. Current security testing methods and tools often only target a single layer or dimension of the hybrid container architecture, lacking systematic analysis and failing to identify the interconnected security risks between different layers. Therefore, a method is needed to comprehensively test the security of hybrid containers. Summary of the Invention

[0004] This specification describes one or more embodiments of a security detection method and apparatus for container images, which are used to perform comprehensive security detection on images of hybrid architecture containers and identify single-dimensional security risks as well as multi-dimensional composite security risks.

[0005] Firstly, a security detection method for container images is provided, wherein the image to be detected includes a container layer, a virtualization layer, and a code implementation layer; the method includes:

[0006] A first security test is performed on the container layer to generate a first test result; the first security test includes a first dynamic test of the container operation status in the container layer and a first anti-attack test of the running container.

[0007] A second security check is performed on the virtualization layer to generate a second check result; the second security check includes obtaining the call chain information of DMA operations in the virtualization management program of the virtualization layer, generating an initial seed based on the call chain information, and performing fuzz testing on the virtualization management program based on test cases that perform mutation operations on the initial seed.

[0008] A third security check is performed on the code implementation layer to generate a third check result; the third security check includes a second dynamic check for runtime vulnerabilities in the code, and a second anti-attack test for the code execution.

[0009] Based on the first detection result, the second detection result, and the third detection result, a security detection result is generated for the image to be detected.

[0010] In some possible implementations, the first security detection further includes a first static detection of files and configuration parameters in the container layer, the first static detection including one or more of the following steps:

[0011] Verify the integrity of each file in the container layer;

[0012] Check the permission settings of each file and directory in the container layer;

[0013] Determine the version information of each software package in the container layer, and then identify software packages with known security vulnerabilities;

[0014] Check whether specific environment variables in the container layer are stored in encrypted form;

[0015] Check the service configuration files in the container layer for security vulnerabilities;

[0016] Check whether the container startup parameters in the container layer contain unsafe options.

[0017] In some possible implementations, the first dynamic detection includes one or more of the following steps:

[0018] Track abnormal CPU, memory, disk I / O, and network bandwidth usage during container runtime;

[0019] Check whether the actual permissions of each process during container runtime are consistent with the preset permissions;

[0020] Check the network isolation between the container and other containers and the host machine.

[0021] In some possible implementations, the first anti-attack test includes one or more of the following steps:

[0022] A security risk assessment test was conducted on the container based on known vulnerabilities.

[0023] Perform fuzz testing and / or vulnerability scanning on the container;

[0024] The password strength assessment test is performed on the services running within the container;

[0025] Perform communication mediation security assessment tests in the network environment of the running container;

[0026] Perform cross-container resource access tests within the container;

[0027] Unauthorized operation compliance verification tests were conducted within the container.

[0028] In some possible implementations, obtaining the call chain information of DMA operations in the virtualization manager of the virtualization layer includes:

[0029] Obtain a list of potentially risky DMA operations from the virtualization management program;

[0030] Construct the function call graph of the virtualization management program and determine several call chains from MMIO / PIO functions to DMA operations.

[0031] In some possible implementations, generating an initial seed based on the call chain information includes:

[0032] Construct the corresponding program dependency graph based on each call chain in the call chain information;

[0033] Based on any program dependency graph, determine the control flow constraints within it;

[0034] Based on the control flow constraints corresponding to each program dependency graph, several initial seeds that satisfy the constraints are generated.

[0035] In some possible implementations, the third security detection further includes: a second static detection targeting code writing vulnerabilities in the code implementation layer; the code writing vulnerabilities include: memory security vulnerabilities, multi-threaded concurrency security vulnerabilities, resource management vulnerabilities, and permission verification vulnerabilities.

[0036] In some possible implementations, the second anti-attack test includes a security risk assessment test for each vulnerability detected in the second static detection and the second dynamic detection.

[0037] In some possible implementations, the runtime vulnerabilities include: memory security vulnerabilities, multithreaded concurrency security vulnerabilities, resource management vulnerabilities, permission verification vulnerabilities, and interface access vulnerabilities.

[0038] In some possible implementations, the security test results include one or more of the following: test scope, tools and methods used, list of problems, problem descriptions, severity assessment, remediation recommendations, and overall security status assessment.

[0039] Secondly, a security detection device for container images is provided, wherein the image to be detected includes a container layer, a virtualization layer, and a code implementation layer; the device includes:

[0040] The first security detection unit is configured to perform a first security detection on the container layer and generate a first detection result; the first security detection includes a first dynamic detection of the container operation status in the container layer and a first anti-attack test on the running container.

[0041] The second security detection unit is configured to perform a second security detection on the virtualization layer and generate a second detection result. The second security detection includes obtaining the call chain information of DMA operations in the virtualization management program of the virtualization layer, generating an initial seed based on the call chain information, and performing fuzz testing on the virtualization management program based on test cases that perform mutation operations on the initial seed.

[0042] The third security detection unit is configured to perform a third security detection on the code implementation layer and generate a third detection result; the third security detection includes a second dynamic detection of runtime vulnerabilities in the code and a second anti-attack test on the code execution.

[0043] The result aggregation unit is configured to generate a security detection result for the image to be detected based on the first detection result, the second detection result, and the third detection result.

[0044] Thirdly, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of the first aspect.

[0045] Fourthly, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the method of the first aspect.

[0046] The security detection method and apparatus for container images proposed in the embodiments of this specification perform security detection on the container layer, virtualization layer, and code implementation layer of the container image to be detected. Specifically, the security detection for the container layer includes dynamic monitoring of the container's operation and a first anti-attack test on the container's operation; the security detection for the virtualization layer includes fuzzing the virtualization management program based on DMA (Direct Memory Access) operations; and the security detection for the code implementation layer includes dynamic detection of runtime vulnerabilities and a second anti-attack test on the code execution. Finally, the security detection results for each layer are summarized and output, achieving comprehensive coverage of software vulnerabilities, configuration defects, and dynamic execution risks in hybrid architecture containers, significantly improving the ability to discover deep vulnerabilities, and supporting precise upstream and downstream location of security risks. Attached Figure Description

[0047] To more clearly illustrate the technical solutions of the various embodiments disclosed in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only a few embodiments disclosed in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 This illustration shows a security detection scenario for a container image according to one embodiment.

[0049] Figure 2 A flowchart illustrating a security detection method for a container image according to one embodiment is shown;

[0050] Figure 3 A schematic block diagram of a security detection apparatus for container images according to one embodiment is shown. Detailed Implementation

[0051] The solution provided in this specification will now be described with reference to the accompanying drawings.

[0052] Current virtualization technologies mainly include container technology and virtual machine technology. Traditional containers (such as Docker containers) achieve isolation between users through namespaces and control groups, and are lightweight. However, in multi-user scenarios, the isolation is limited, posing security risks. Virtual machines rely on hardware virtualization, offering strong isolation and high security, but they have slow startup speeds and high resource consumption.

[0053] Therefore, a hybrid architecture container was proposed as a technical solution. The hybrid architecture container combines the advantages of traditional container and virtual machine technologies. It starts a lightweight virtual machine monitor (also known as a virtualization manager) inside each container instance and runs the container process in this lightweight virtual machine to balance security and performance.

[0054] Hybrid architecture containers typically consist of a container layer, a virtualization layer, and a code implementation layer. The container layer hosts the actual application process and is provided by a standard OCI (Open Container Initiative) container image. The virtualization layer serves as a lightweight virtual machine image for booting the hybrid architecture container, containing the Linux kernel, a streamlined root file system, and a container management agent, forming the minimum execution environment for container operation. The code implementation layer is used to develop the core components of the hybrid architecture container (such as the agent and runtime programs). Together, these three layers construct a virtualized container runtime system that balances security isolation with performance.

[0055] However, as the application of hybrid container architectures continues to expand, they still face many potential security issues, thus requiring security testing to improve overall security. Security testing tools in related technologies typically only target a single technology such as container technology or virtualization technology, making it difficult to conduct a systematic and comprehensive security analysis of hybrid container architectures.

[0056] To solve the above problems, Figure 1 This diagram illustrates a security detection scenario for a container image according to one embodiment. Figure 1 As shown, a container image can be any image of a hybrid architecture container, comprising a container layer, a virtualization layer, and a code implementation layer. The security testing of hybrid architecture container images in this specification includes security testing of each of the three layers: the container layer, the virtualization layer, and the code implementation layer.

[0057] Security testing at the container layer includes: static security testing of files and configuration parameters within the container layer; dynamic security testing of the container's operational status; and testing of the attack resistance of running containers. The results of these tests are then combined to generate the first detection result for the container layer.

[0058] Security testing of the virtualization layer includes: fuzzing of the virtualization hypervisor within the virtualization layer, guided by DMA operations. Based on the fuzzing results, a second detection result for the virtualization layer is then generated.

[0059] Security testing at the code implementation layer includes: static security testing for vulnerabilities in the code writing process, dynamic security testing for vulnerabilities generated during code runtime, and attack resistance testing of the runtime code. The results of these tests are then combined to generate a third set of testing results for the code implementation layer.

[0060] Furthermore, the results of the aforementioned security tests are summarized and analyzed to produce a comprehensive security analysis report for hybrid architecture container images. This report includes the scope of security testing, the tools and methods used, a list of security issues, descriptions of the security issues, severity assessments, remediation recommendations, and an overall security status assessment.

[0061] The specific methods for each of the above safety tests will be described in detail later in this manual.

[0062] The following describes the specific implementation steps of the above-mentioned security detection method for container images, with reference to specific embodiments.

[0063] Figure 2A flowchart illustrating a security detection method for container images according to one embodiment is provided. The entity executing the method can be any platform, server, or device cluster with computing and processing capabilities. Figure 2 As shown, the image to be tested includes a container layer, a virtualization layer, and a code implementation layer; the method includes at least the following steps: Step S202, performing a first security test on the container layer and generating a first test result; the first security test includes a first dynamic test of the container's running status in the container layer and a first anti-attack test on the running container; Step S204, performing a second security test on the virtualization layer and generating a second test result; the second security test includes obtaining the call chain information of DMA operations in the virtualization manager of the virtualization layer, generating an initial seed based on the call chain information, and performing fuzz testing on the virtualization manager based on test cases that perform mutation operations on the initial seed; Step S206, performing a third security test on the code implementation layer and generating a third test result; the third security test includes a second dynamic test of the code runtime vulnerability and a second anti-attack test on the code execution; Step S208, generating a security test result for the image to be tested based on the first test result, the second test result, and the third test result.

[0064] The image to be tested can be an image of the aforementioned hybrid architecture container, which includes a container layer, a virtualization layer, and a code implementation layer. The specific execution process of each of the above steps is described below.

[0065] In step S202, a first security test is performed on the container layer to generate a first test result; the first security test includes a first dynamic test of the container operation status in the container layer and a first anti-attack test of the running container.

[0066] The container mentioned in step S202 can be a container instance running based on the image to be detected. The first dynamic detection is used to perform security checks on the operation of the container in its running state.

[0067] In one embodiment, step S202, the first dynamic detection, includes one or more of the following steps 11 to 13:

[0068] In step 11, track abnormal usage of CPU, memory, disk I / O, and network bandwidth during container runtime.

[0069] Based on specific needs, separate warning thresholds can be set for CPU utilization, memory usage, disk I / O (write / read) latency, and network bandwidth traffic, and the items that trigger the thresholds, their specific values, occurrence times, durations, etc., can be recorded.

[0070] In step 12, check whether the actual permissions of each process running in the container are consistent with the preset permissions.

[0071] System call tracing tools (such as the `strace` command) can be used to trace the system call behavior of processes within a container and check whether the actual permissions of the processes are consistent with expectations. When a process is found to have acquired permissions beyond expectations, the process name, a list of unexpected permissions, the time of occurrence, etc., should be recorded.

[0072] A process's expected permission list can be recorded, for example, by the Capabilities permission set. The Capabilities permission set is a fine-grained permission control mechanism provided by the Linux kernel. It breaks down the super privileges of the traditional root user into multiple independent capability units, restricts the actual permission range of processes within the container, and reduces the risk of privilege abuse.

[0073] In step 13, the network isolation between the container and other containers and the host machine is checked.

[0074] Network tools (such as nmap) can be used to test network isolation between multiple containers running on the container platform, as well as network isolation between containers and the host machine. Simultaneously, attempt to access the file systems of other containers or the host machine from within the current container to check isolation. If the test results reveal successfully accessed network ports and / or file paths that should not have been open, record those network ports and / or file paths.

[0075] By using one or more steps from steps 11 to 13, the operational status of the container in operation can be safely monitored, and any safety issues that arise can be recorded.

[0076] In one embodiment, step S202, the first anti-attack test, includes one or more of the following steps 21 to 26:

[0077] In step 21, a security risk assessment test is performed on the container based on known vulnerabilities.

[0078] You can use vulnerability scanning tools (such as Metasploit) to test for known vulnerabilities and record a list of exploitable vulnerabilities.

[0079] In step 22, the container is subjected to fuzz testing and / or vulnerability scanning.

[0080] Fuzzing can be used with fuzzing tools (such as AFL (American Fuzzy Lop)) to perform automated input mutation testing on services within containers, generate anomalous inputs and track program behavior, and capture crash or exception logs to identify potential vulnerabilities.

[0081] Vulnerability scanning can be performed by using vulnerability scanning tools (such as Metasploit) to match patterns of known vulnerability characteristics and by using dynamic instrumentation techniques to analyze abnormal behaviors such as runtime memory states and system calls.

[0082] By cross-validating the abnormal results of fuzz testing with the abnormal behaviors discovered by vulnerability scanning, the specific triggering paths and impact scope of the located vulnerabilities (some of which may be zero-day vulnerabilities) are recorded.

[0083] In step 23, a password strength evaluation test is performed on the service running within the container.

[0084] Passwords can be tested against those of services running within the container based on a password dictionary to assess the password strength of each service. A list of services that successfully pass the tests is then recorded.

[0085] In step 24, a communication intermediary security assessment test is performed in the network environment of the running container.

[0086] In a container network environment, a man-in-the-middle (MitM) attack can be simulated to check for unencrypted or weakly encrypted channels and assess the risk of leakage of confidential information (such as authentication tokens and configuration file contents).

[0087] In step 25, cross-container resource access tests are performed in the container.

[0088] Within the container, the external interface of the container can be used to attempt to access resources in other containers within the container platform, and the containers that can be successfully accessed, the resource paths, and the interfaces used, etc., can be recorded.

[0089] In step 26, an unauthorized operation compliance verification test is performed within the container.

[0090] Within the container, you can attempt to escalate privileges through exploits or misconfigurations. Record any successful escalation attempts, including the vulnerabilities or misconfigurations used and the specific permissions employed.

[0091] By using one or more of steps 21 to 26, anti-attack detection can be performed on the running container, and any security issues that arise can be recorded.

[0092] In some possible implementations, the first security detection in step S202 further includes a first static detection of files and configuration parameters in the container layer, the first static detection including one or more of steps 31 to 36:

[0093] In step 31, the integrity of each file in the container layer is verified.

[0094] Calculate the hash value of all files within the container image and compare it with a list of valid hash values ​​(hash value verification) to verify file integrity. If the hash value of a file differs from its corresponding valid hash value, then that file is either tampered with or missing. Record all files within the container image that fail the hash value verification.

[0095] In step 32, the permission settings of each file and directory in the container layer are checked.

[0096] Traverse the image files and directories, checking that the permissions of each file match expectations. Simultaneously, use a file type identification tool (e.g., the `file` command) to confirm file types. File types are used to comprehensively determine whether related files pose security risks; for example, whether executable files have permissions set to allow execution by any user. Record any files / paths with abnormal permissions, along with the corresponding abnormal permissions.

[0097] In step 33, the version information of each software package in the container layer is determined, thereby identifying software packages with known security vulnerabilities.

[0098] By parsing the package management file of a container image, a list of installed software packages and their version information can be obtained. This information can then be compared with a vulnerability database to identify known security vulnerabilities. Furthermore, package dependencies can be analyzed to ensure that dependencies are correctly installed and version compatible. The system records the software packages containing known security vulnerabilities and their version information.

[0099] In step 34, check whether specific environment variables in the container layer are stored in encrypted form.

[0100] By examining the environment variable configurations in the container image, it's possible to determine whether each environment variable in the pre-defined sensitive information list is stored encrypted. A list of environment variables that are not stored encrypted (in plaintext) is then recorded.

[0101] In step 35, check whether there are any security vulnerabilities in the service configuration files in the container layer.

[0102] Use static analysis tools (such as kata-lint) to parse and verify the syntax correctness of the service configuration files, and check for any insecure options enabled. Record any erroneous syntax and insecure options.

[0103] In step 36, check whether the container startup parameters in the container layer contain unsafe options.

[0104] By examining the container startup parameters, ensure that no known high-risk parameters are used. Record any unsafe parameters detected.

[0105] By using one or more steps from steps 31 to 36, security risks in non-running image files can be assessed and security issues arising therefrom can be recorded.

[0106] Through the various detection methods in step S202, comprehensive security detection of the container layer of the image to be tested can be performed at the static level, dynamic level, and anti-attack testing level.

[0107] Back Figure 2 In step S204, a second security test is performed on the virtualization layer to generate a second test result. The second security test includes obtaining the call chain information of DMA operations in the virtualization management program of the virtualization layer, generating an initial seed based on the call chain information, and performing fuzz testing on the virtualization management program based on test cases that perform mutation operations on the initial seed.

[0108] The hypervisor is used to manage the lifecycle of virtual machines, perform resource virtualization and isolation, etc., within the virtualization layer. The second security test is based on DMA operation bootstrapping and fuzz testing of the hypervisor.

[0109] In one embodiment, step S204, which involves obtaining the call chain information of DMA operations in the virtualization management program of the virtualization layer, includes steps 41 and 42.

[0110] In step 41, the virtualization management program obtains a list of DMA operations that contain potential risks.

[0111] The source code of the virtualization hypervisor is compiled to generate LLVM intermediate language files. Static analysis tools can then be used to extract function call information, including a list of potentially risky DMA operations.

[0112] In step 42, a function call graph of the virtualization management program is constructed, and several call chains from MMIO / PIO functions to DMA operations are determined from it.

[0113] Based on the call relationships between functions in the virtualization hypervisor, a function call graph is constructed. From this graph, several call chains from callback functions in MMIO / PIO (Memory-Mapped I / O, Programmed I / O) mode to DMA operations can be determined.

[0114] In one embodiment, step S204 generates an initial seed based on the call chain information, including steps 51 to 53.

[0115] In step 51, a corresponding program dependency graph is constructed based on each call chain in the call chain information.

[0116] For each collected call chain, construct a program dependency graph for all function statements on it, where nodes represent statements and edges represent control dependencies and data dependencies.

[0117] In step 52, the control flow constraints are determined based on any program dependency graph.

[0118] For each node in the program dependency graph corresponding to a function in the call chain, if the node is a function call statement or a return statement, then the control dependency node associated with it is added to the constraint set.

[0119] Next, for each node in the constraint set, obtain its data dependency nodes and add them to the data set. For nodes added to the data set, extract their control dependencies again and add them to the constraint set. Repeat this step until no new nodes are added to the constraint set. Use each control dependency node in the constraint set as a control flow constraint.

[0120] In step 53, several initial seeds that satisfy the constraints are generated based on the control flow constraints corresponding to each program dependency graph.

[0121] For each control-dependent node, determine whether its variables can be directly controlled by the input, such as MMIO base address offset (addr), input data (data), and data length (size). Then, convert these nodes that can be directly controlled by the input into specific input values ​​through the construction function, add them to the seed set, and return the initial seed.

[0122] In one embodiment, step S204, which involves performing fuzz testing on the virtualization management program based on test cases that perform mutation operations on the initial seed, includes:

[0123] First, add evaluation criteria related to DMA operations to the fuzzing tool (such as AFL++).

[0124] Then, based on the program dependency graph constructed in step 51, only the fields that affect the DMA operation call parameters are randomly or strategically mutated.

[0125] Next, the mutated test cases are input into the virtualization management program to trigger DMA operations. DMA function calls are recorded, and inputs that can trigger DMA operations and generate new coverage are selected.

[0126] Continue the above cycle until the preset duration or the number of test cases threshold is reached, or it becomes difficult to cover new DMA paths.

[0127] Step S204 allows for the discovery of abnormal behavior and potential security vulnerabilities in the virtualization layer based on fuzz testing.

[0128] Back Figure 2 In step S206, a third security check is performed on the code implementation layer to generate a third check result; the third security check includes a second dynamic check for runtime vulnerabilities of the code and a second anti-attack test for the code execution.

[0129] In one embodiment, the code runtime vulnerability mentioned in step S206 includes: memory security vulnerability, multi-threaded concurrency security vulnerability, resource management vulnerability, permission verification vulnerability, and interface access vulnerability.

[0130] Memory testing tools (such as Valgrind) can be used to detect memory security vulnerabilities such as memory leaks and out-of-bounds access, and record the memory security vulnerabilities, their types, locations, etc., found during the detection.

[0131] Concurrency analysis tools (such as Racer) can be used to capture multi-threaded concurrency safety issues such as data races and deadlocks, and record the variable names, locations, thread IDs, etc., in which the races occur.

[0132] Resource usage tracers (such as jemalloc) can be used to track program resource usage and release. They can record resources that were correctly released, the thread IDs that used those resources, and so on.

[0133] It can build multi-role, multi-permission environments, test the effectiveness of the permission management mechanism under different permission environments, and record any unauthorized behaviors.

[0134] API testing tools (such as Postman) can be used to dynamically test API interfaces, such as boundary value testing, SQL injection, etc., and record the methods used to cause API interface anomalies and the related API interfaces.

[0135] Through the second dynamic detection, a comprehensive and accurate dynamic detection of runtime security at the code implementation layer can be performed, and security risks in multiple dimensions such as memory, concurrency, resources, permissions, and interfaces can be detected in a timely manner.

[0136] In a more specific embodiment, step S206, the second anti-attack test, includes a security risk assessment test for each vulnerability detected in the second dynamic detection.

[0137] For the potential security vulnerabilities discovered in the second dynamic detection, corresponding simulated attacks were conducted to verify the exploitability and severity of the vulnerabilities. The simulated attack methods for each vulnerability and the resulting insecurity outcomes were recorded.

[0138] In some possible implementations, the third security detection in step S206 further includes: a second static detection of code writing vulnerabilities in the code implementation layer; the code writing vulnerabilities include: memory security vulnerabilities, multi-threaded concurrency security vulnerabilities, resource management vulnerabilities, and permission verification vulnerabilities.

[0139] Static code analysis tools (such as Clippy) can be used to scan the code implementation layer to detect memory safety vulnerabilities such as raw pointer operations, dangling pointers, and double-free; concurrency security issues such as data races in multi-threaded environments; resource management issues such as improperly released file handles; privilege escalation vulnerabilities; and security issues such as improper input validation, lack of authentication or authorization in API interfaces. Record all security vulnerabilities found during the entire scan process, including their types and locations.

[0140] Based on the detection results of the second static detection, in a more specific embodiment, step S206, the second anti-attack test, includes a security risk assessment test for each vulnerability detected in the second static detection and the second dynamic detection.

[0141] For potential security vulnerabilities discovered in the second static detection and second dynamic detection, corresponding simulated attacks were conducted to verify the exploitability and severity of the vulnerabilities. The simulated attack methods for each vulnerability and the resulting insecurity outcomes were recorded.

[0142] Through the various detection methods in step S206, comprehensive security detection can be performed on the code implementation layer of the image to be tested at the static level, dynamic level, and anti-attack testing level.

[0143] It should be noted that there is no fixed execution order among the above steps S202, S204 and S206. The above steps can be executed in any order or in parallel. No restrictions are imposed here.

[0144] Finally, in step S208, a security detection result is generated for the image to be detected based on the first detection result, the second detection result, and the third detection result.

[0145] By summarizing the security vulnerabilities and / or issues discovered in static security testing, dynamic security testing, anti-attack testing, and fuzzing of each layer in the image under test, the severity and potential impact of each vulnerability and / or issue are determined according to its type, and corresponding remediation suggestions are provided based on conventional remediation methods. Finally, based on the severity and potential impact of each vulnerability and / or issue, an overall security assessment of the image under test is determined.

[0146] In one embodiment, the security detection results include one or more of the following: detection scope, tools and methods used, problem list, problem description, severity assessment, remediation recommendations, and overall security status assessment.

[0147] The security detection method for container images according to the embodiments of this specification performs collaborative analysis on the container, virtualization layer, and code implementation layer of the hybrid architecture container image to be detected. This overcomes the limitations of single-dimensional detection, achieving comprehensive coverage of software vulnerabilities, configuration defects, dynamic execution risks, and supply chain dependencies. It significantly improves the ability to discover deep vulnerabilities and supports precise upstream and downstream location of security risks. Furthermore, the embodiments of this specification, through an efficient and low-cost detection process and cross-dimensional data correlation analysis, can effectively identify security vulnerabilities corresponding to composite attack paths.

[0148] According to another embodiment, a security detection device for container images is also provided. Figure 3 This diagram illustrates a schematic block diagram of a security inspection apparatus for container images according to one embodiment. This apparatus can be deployed in any device, platform, or cluster of devices with computing and processing capabilities. The image to be inspected includes a container layer, a virtualization layer, and a code implementation layer. Figure 3 As shown, the device 300 includes:

[0149] The first security detection unit 302 is configured to perform a first security detection on the container layer and generate a first detection result; the first security detection includes a first dynamic detection of the container operation status in the container layer and a first anti-attack test on the running container.

[0150] The second security detection unit 304 is configured to perform a second security detection on the virtualization layer and generate a second detection result. The second security detection includes obtaining the call chain information of DMA operations in the virtualization management program of the virtualization layer, generating an initial seed based on the call chain information, and performing fuzz testing on the virtualization management program based on test cases that perform mutation operations on the initial seed.

[0151] The third security detection unit 306 is configured to perform a third security detection on the code implementation layer and generate a third detection result; the third security detection includes a second dynamic detection of runtime vulnerabilities in the code and a second anti-attack test on the code execution.

[0152] The result aggregation unit 308 is configured to generate a security detection result for the image to be detected based on the first detection result, the second detection result, and the third detection result.

[0153] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform the methods described in any of the above embodiments.

[0154] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the method described in any of the above embodiments.

[0155] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0156] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0157] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0158] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0159] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A security detection method for container images, wherein the image to be detected includes a container layer, a virtualization layer, and a code implementation layer; the method includes: A first security check is performed on the container layer to generate a first check result; The first security detection includes a first dynamic detection of the container operation status in the container layer, and a first anti-attack test for the running containers; A second security check is performed on the virtualization layer to generate a second check result; The second security detection includes obtaining the call chain information of DMA operations in the virtualization management program of the virtualization layer, generating an initial seed based on the call chain information, and performing fuzz testing on the virtualization management program based on test cases that perform mutation operations on the initial seed; A third security check is performed on the code implementation layer to generate a third check result; The third security detection includes a second dynamic detection of the code runtime vulnerability and a second anti-attack test of the code execution. Based on the first detection result, the second detection result, and the third detection result, a security detection result is generated for the image to be detected.

2. The method according to claim 1, wherein, The first security detection also includes a first static detection of files and configuration parameters in the container layer, the first static detection including one or more of the following steps: Verify the integrity of each file in the container layer; Check the permission settings of each file and directory in the container layer; Determine the version information of each software package in the container layer, and then identify software packages with known security vulnerabilities; Check whether specific environment variables in the container layer are stored in encrypted form; Check the service configuration files in the container layer for security vulnerabilities; Check whether the container startup parameters in the container layer contain unsafe options.

3. The method according to claim 1, wherein, The first dynamic detection includes one or more of the following steps: Track abnormal CPU, memory, disk I / O, and network bandwidth usage during container runtime; Check whether the actual permissions of each process during container runtime are consistent with the preset permissions; Check the network isolation between the container and other containers and the host machine.

4. The method according to claim 1, wherein, The first anti-attack test includes one or more of the following steps: A security risk assessment test was conducted on the container based on known vulnerabilities. Perform fuzz testing and / or vulnerability scanning on the container; The password strength assessment test is performed on the services running within the container; Perform communication mediation security assessment tests in the network environment of the running container; Perform cross-container resource access tests within the container; Unauthorized operation compliance verification tests were conducted within the container.

5. The method according to claim 1, wherein, Obtain the call chain information of DMA operations in the virtualization management program of the virtualization layer, including: Obtain a list of potentially risky DMA operations from the virtualization management program; Construct the function call graph of the virtualization management program and determine several call chains from MMIO / PIO functions to DMA operations.

6. The method according to claim 1, wherein, Generate an initial seed based on the call chain information, including: Construct the corresponding program dependency graph based on each call chain in the call chain information; Based on any program dependency graph, determine the control flow constraints within it; Based on the control flow constraints corresponding to each program dependency graph, several initial seeds that satisfy the constraints are generated.

7. The method according to claim 1, wherein, The third security detection also includes: a second static detection targeting code writing vulnerabilities in the code implementation layer; the code writing vulnerabilities include: memory security vulnerabilities, multi-threaded concurrency security vulnerabilities, resource management vulnerabilities, and permission verification vulnerabilities.

8. The method according to claim 7, wherein, The second anti-attack test includes a security risk assessment test for each vulnerability detected in the second static detection and the second dynamic detection.

9. The method according to claim 1, wherein, The runtime vulnerabilities mentioned include: memory security vulnerabilities, multi-threaded concurrency security vulnerabilities, resource management vulnerabilities, permission verification vulnerabilities, and interface access vulnerabilities.

10. The method according to claim 1, wherein, The security test results include one or more of the following: scope of testing, tools and methods used, list of issues, problem descriptions, severity assessment, remediation recommendations, and overall security status assessment.

11. A security detection device for container images, wherein the image to be detected includes a container layer, a virtualization layer, and a code implementation layer; The device includes: The first security detection unit is configured to perform a first security detection on the container layer and generate a first detection result; the first security detection includes a first dynamic detection of the container operation status in the container layer and a first anti-attack test on the running container. The second security detection unit is configured to perform a second security detection on the virtualization layer and generate a second detection result. The second security detection includes obtaining the call chain information of DMA operations in the virtualization management program of the virtualization layer, generating an initial seed based on the call chain information, and performing fuzz testing on the virtualization management program based on test cases that perform mutation operations on the initial seed. The third security detection unit is configured to perform a third security detection on the code implementation layer and generate a third detection result; the third security detection includes a second dynamic detection of runtime vulnerabilities in the code and a second anti-attack test on the code execution. The result aggregation unit is configured to generate a security detection result for the image to be detected based on the first detection result, the second detection result, and the third detection result.

12. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-10.

13. A computing device comprising a memory and a processor, wherein, The memory stores executable code, and when the processor executes the executable code, it implements the method of any one of claims 1-10.

Images