Container image detection method, storage medium, program product, and electronic device

Abstract

This specification discloses a container image detection method, storage medium, program product, and electronic device, relating to the field of computer technology. In this specification, the hierarchical structure of a container image is parsed to obtain file lists corresponding to multiple layers. Further, a layer-by-layer comparison is performed based on the file lists of each layer to identify target files whose information has changed in at least two layers. An information change record of the target files throughout the entire container image lifecycle is constructed. Based on the information change records corresponding to at least one target file, static scanning, dynamic behavior analysis, and cross-layer dependency analysis are performed on the container image to obtain a risk detection report indicating the malicious content included in the container image. The container image detection method provided in this specification can solve the problem of inaccurate location of malicious content in deep images, enabling rapid discovery and response to potential risks within container images, thus improving the security of container images.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a container image detection method, storage medium, program product, and electronic device. Background Technology

[0002] In recent years, with the rapid development and widespread application of cloud-native technologies, container technology has become the mainstream for microservice architecture deployment. Specifically, container technology significantly improves the efficiency and consistency of software development, testing, and deployment by packaging applications and their runtime dependencies into standardized, portable image units.

[0003] However, container images themselves are usually composed of multiple read-only layers, each representing file changes or dependencies introduced by a build operation. While this layered structure is beneficial for image reuse and incremental updates, it also provides potential space for the implantation and hiding of malicious code.

[0004] For example, attackers may exploit intermediate layers during the image build process to embed hidden backdoors, mining scripts, data-stealing modules, or other forms of malicious payloads. These malicious components are often deliberately distributed deep within the image layers, and may even evade conventional detection by obfuscating, encrypting, or disguising themselves as legitimate system files. Furthermore, in complex build processes such as multi-stage builds, some intermediate layers, although invisible in the final image, may still retain sensitive information or malicious code, further increasing security risks.

[0005] Existing malware detection solutions are mostly based on static file scanning or runtime behavior monitoring. However, when faced with complex container images, existing technologies often struggle to accurately identify and locate malware hidden deep within the image layers, resulting in limitations such as large detection blind spots, high false positive rates, and weak source tracing capabilities. Summary of the Invention

[0006] This specification provides a container image detection method, storage medium, program product, and electronic device, which can solve the above-mentioned problems. The technical solution is as follows: Firstly, embodiments of this specification provide a container image detection method, the method comprising: Obtain the container image, parse the hierarchical structure of the container image, and obtain a file list corresponding to each layer; wherein, the file list includes at least one file; Based on the file list of each layer, compare layer by layer to determine the target file in which information has changed in at least two layers, and track the information change record of the target file across layers; Based on the information change records corresponding to at least one of the target files, static scanning, dynamic behavior analysis, and cross-layer dependency analysis are performed on the container image to obtain a risk detection report.

[0007] Secondly, embodiments of this specification provide a container image detection device, the device comprising: The container acquisition module is used to acquire a container image, parse the hierarchical structure of the container image, and obtain a file list corresponding to each of the multiple layers; wherein, the file list includes at least one file; The file recording module is used to compare the file lists of each layer layer by layer to determine the target file whose information has changed in at least two layers, and to track the information change records of the target file across layers. The risk analysis module is used to perform static scanning, dynamic behavior analysis, and cross-layer dependency analysis on the container image based on the information change records corresponding to at least one of the target files, and to obtain a risk detection report.

[0008] Thirdly, embodiments of this specification provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the above-described method steps.

[0009] Fourthly, embodiments of this specification provide a computer program product that stores multiple instructions adapted for loading by a processor and executing the above-described method steps.

[0010] Fifthly, embodiments of this specification provide an electronic device that may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the above-described method steps.

[0011] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following: This specification parses the hierarchical structure of a container image, obtaining file lists corresponding to multiple layers. Further, it compares each layer's file list layer by layer to accurately identify target files whose information has changed in at least two layers, and performs cross-layer tracking of these target files, constructing a record of information changes for each target file throughout the container image's lifecycle. Based on the information change records corresponding to at least one target file, it performs static scanning, dynamic behavior analysis, and cross-layer dependency analysis on the container image, generating a risk detection report indicating the malicious content included in the container image. This specification utilizes container layer parsing technology to comprehensively analyze the hierarchical structure of container images and the potential malicious content within layered files, offering broad coverage. It focuses on target files with changed information for risk detection, accurately locating risk sources and improving detection accuracy. Furthermore, this method is applicable to various container image formats and container images built using different methods, demonstrating good adaptability and enabling rapid discovery and response to potential risks within container images, thus improving container image security. Attached Figure Description

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

[0013] Figure 1 This is a schematic diagram of the architecture of a container image detection method provided in the embodiments of this specification; Figure 2 This is a schematic flowchart of a container image detection method provided in the embodiments of this specification; Figure 3 This is a schematic diagram illustrating an embodiment of the present specification for obtaining a multi-level file list; Figure 4 This is a schematic diagram illustrating an embodiment of the present specification for obtaining a multi-level file list; Figure 5 This is a schematic flowchart of a container image detection method provided in the embodiments of this specification; Figure 6 This is a schematic diagram of a process for outputting a static scan report provided in an embodiment of this specification; Figure 7 This is a schematic flowchart of a container image detection method provided in the embodiments of this specification; Figure 8 This is a schematic diagram of the structure of a container mirror detection device provided in the embodiments of this specification; Figure 9This is a schematic diagram of the structure of an electronic device provided in the embodiments of this specification. Detailed Implementation

[0014] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0015] In the description of this specification, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. In the description of this specification, it should be noted that, unless otherwise expressly specified and limited, "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. Those skilled in the art can understand the specific meaning of the above terms in this specification based on the specific circumstances. Furthermore, in the description of this specification, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0016] The present specification will now be described in detail with reference to specific embodiments.

[0017] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the features, information, and data involved in this specification were all obtained under full authorization.

[0018] like Figure 1 As shown, Figure 1 This is a schematic flowchart of a container image detection method provided in the embodiments of this specification. Figure 1The system includes at least a server 101 that executes the container image detection method, and multiple electronic devices that store container images or initiate container image detection requests. These multiple electronic devices include at least electronic device 1021, electronic device 1022, and electronic device 1023. It is understood that... Figure 1 The number of servers and electronic devices shown is for illustrative purposes only, and the embodiments in this specification do not impose any limitations on them.

[0019] The aforementioned server 101 can be a standalone server device, such as a rack-mount, blade, tower, or cabinet-type server device, or a workstation, mainframe, or other hardware device with strong computing power; it can also be a server cluster composed of multiple servers. The servers in the service cluster can be composed in a symmetrical manner, where each server is functionally and hierarchically equivalent in the transaction chain, and each server can provide services to the outside world independently. Providing services independently can be understood as not requiring the assistance of other servers.

[0020] For example, a server can be multiple physical servers, each with independent hardware. Alternatively, a server can be multiple virtual servers deployed within the same hardware resource pool. Virtual server deployment methods include, but are not limited to, VMware, VirtualBox, and Virtual PC.

[0021] It is understood that server 101 also possesses other service capabilities and functions to complete the tasks described in the following embodiments. For example, server 101 also provides portal services, resource management services, and CI / CD services, etc.

[0022] Electronic devices include, but are not limited to: wearable devices, handheld devices, personal computers, tablets, in-vehicle devices, smartphones, computing devices, or other processing devices connected to a wireless modem. Electronic devices may have different names in different networks, such as: user equipment, access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent or user device, cellular phone, cordless phone, personal digital assistant (PDA), and electronic devices in 5G networks or future evolved networks.

[0023] In the embodiments of this specification, electronic devices such as electronic devices 1021, 1022, and 1023 may also be equipped with display devices. These display devices can be various devices capable of display functions, such as cathode ray tube displays (CR), light-emitting diode displays (LED), electronic ink screens, liquid crystal displays (LCD), and plasma display panels (PDP). For example, a user can use the display device on electronic device 1021 to view a risk assessment report for a container image.

[0024] Multiple electronic devices and multiple servers can communicate through communication links established by communication protocols. For example, the network can be a wireless network or a wired network. Wireless networks include, but are not limited to, cellular networks, wireless LANs, infrared networks, or Bluetooth networks. Wired networks include, but are not limited to, Ethernet, universal serial bus (USB), or controller area networks. In one or more embodiments of the specification, technologies and / or formats including Hyper Text Markup Language (HTML), Extensible Markup Language (XML), etc., are used to represent data exchanged over the network (such as target compressed packets). Furthermore, conventional encryption technologies such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), and Internet Protocol Security (IPsec) can be used to encrypt all or some of the links. In other embodiments, customized and / or dedicated data communication technologies can be used to replace or supplement the aforementioned data communication technologies.

[0025] In one embodiment, such as Figure 2 The diagram shown is a flowchart illustrating a container image detection method provided in an embodiment of this specification. This method can be implemented using a computer program and can run on a container image detection device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application.

[0026] Specifically, the container image detection method includes: S102. Obtain the container image, parse the hierarchical structure of the container image, and obtain the file list corresponding to each layer.

[0027] A container image is a lightweight, standalone executable package that contains the data needed to run an application: code, runtime environment, system tools, library files, and configuration. Container images are presented as read-only templates and are instantiated as writable containers at runtime.

[0028] Container images use a layered filesystem, consisting of multiple read-only layers stacked on top of each other, with a writable container layer (which only exists at runtime) stacked on top of the top layer. Each layer represents a snapshot of filesystem changes generated by a single build operation (such as Dockerfile instructions like RUN, COPY, ADD, etc.).

[0029] The core of parsing the hierarchical structure of a container image is extracting its metadata and the content of each layer. Methods for parsing the hierarchical structure of a container image can include using standard tools (such as `docker save` and `docker unpack`), or using an OCI-compatible library to perform programmatic analysis of the container image's hierarchical structure.

[0030] The hierarchical structure of the container image is parsed, and each image layer after decompression is traversed to extract file-level structure information, including file (such as file name, file type, size, and modification permissions) and directory metadata, and a file list for that image layer is generated. The file list includes at least one file.

[0031] like Figure 3 As shown, Figure 3 This is a schematic diagram illustrating how to obtain file lists corresponding to different layers, as provided in an embodiment of this specification. Container image 201 includes a Base OS layer, Layer 1, Layer 2, Layer 3, Layer ..., Layer N-2, Layer N-1, and Layer N, resulting in multiple file lists corresponding to each layer, including file list 2021 corresponding to the Base OS layer, file list 2022 corresponding to Layer 1, file list 2023 corresponding to Layer 2, file list 2024 corresponding to Layer 3, file list 2025 corresponding to Layer N-2, file list 2026 corresponding to Layer N-1, and file list 2027 corresponding to Layer N.

[0032] S104. Based on the file list of each layer, compare the files layer by layer to determine the target file whose information has changed in at least two layers, and track the information change records of the target file across layers.

[0033] In the context of container images, "information change" refers to any of the following differences that occur in different layers of the same file (usually identified by a path): content change (e.g., different sha256 hash value), permission change (e.g., from 644 to 755), owner change (e.g., change of uid or gid), path change (e.g., the file is moved or renamed), type change (e.g., a regular file becomes a symbolic link), or existence change (a layer exists, but subsequent layers are deleted).

[0034] Based on the file lists of each layer, the file lists of adjacent layers are compared layer by layer to obtain the differences between the file lists of adjacent layers. For example, ... Figure 3 As shown, the file lists of Layer 1 and Layer 2 are compared, the file lists of Layer 2 and Layer 3 are compared, and the file lists of Layer N-2 and Layer N-1 are compared.

[0035] Based on the differences in file lists between multiple adjacent layers, the target file whose information has changed in at least two layers is identified. For example, if the target file belongs to Layer 1 and Layer 2, comparing the file lists of Layer 1 and Layer 2 reveals differences. This indicates that the target file's content has been modified or deleted from Layer 1 through Layer 2, and that the file type has changed from Layer 2 through Layer 3. Therefore, it is determined that the target file has undergone information changes in at least two layers.

[0036] Based on the file information corresponding to the multiple mirror layers to which the target file belongs, the information change records of the target file are tracked across layers. The information change records represent the change history of the target file across multiple mirror layers, as well as the change information between adjacent layers within the multiple mirror layers it spans.

[0037] S106. Based on the information change records corresponding to at least one target file, perform static scanning, dynamic behavior analysis, and cross-layer dependency analysis on the container image to obtain a risk detection report.

[0038] Static analysis refers to the analysis of the file content, configuration, and dependencies in a container image without running the container image, in order to discover potential risks such as hard-coded credentials, known vulnerable components, malicious scripts, and dangerous configurations.

[0039] Dynamic Behavior Analysis refers to running container images or container image files in a simulated environment and monitoring the behavior of the container images or files during runtime (such as network, file, process, system call behavior, etc.) in order to capture hidden malicious behaviors (such as reverse shell, cryptocurrency mining, data leakage).

[0040] Cross-Layer Dependency Analysis refers to analyzing the build dependencies, reference relationships, and call chains between a target file and other layers and other files, thereby identifying potential risks such as supply chain contamination and indirectly introduced malicious dependencies.

[0041] In this specification, when performing static scanning, dynamic behavior analysis, and cross-layer dependency analysis on container images, it is necessary to perform these operations based on the information change records corresponding to at least one target file.

[0042] For example, analyzing the information change records corresponding to the target file allows for static scanning of target files with suspicious information changes. Specifically, based on the information change records, the final content of the target file in Layer 4 is determined. The file content is then extracted from Layer.tar in Layer 4, and a static scan is performed on that target file. This includes checking for suspicious patterns such as curl http: / / malicious.com, base64 decoding, and eval; detecting hard-coded AWS_SECRET and SSH private keys; and checking for linked malicious libraries (such as libmal.so). By focusing on target files with suspicious information changes for static scanning, efficiency can be improved by skipping unchanged base files and reducing noise interference during scanning.

[0043] For example, based on the information change records corresponding to each target file, dynamic behavior analysis is performed only on target files whose information changes conform to preset change conditions. For instance, only target files with information changes such as "granted executable permissions or whose content has been tampered with" are placed in a simulated environment for dynamic behavior analysis to monitor for risky behaviors such as initiating external connections (DNS queries, HTTP requests to abnormal IPs) or writing to sensitive paths. By performing dynamic behavior analysis only on target files containing malicious logic, alerts are avoided due to the behavior of non-target files, thus improving the detection rate.

[0044] For example, based on the multiple change information and the multiple image layers to which the target file belongs in the information change record of the target file, the dependency source of the target file can be traced in reverse, the potential risks of the dependency source can be detected, the scope of the impact of the target file can be deduced in the forward deduction of the dependency, and the call chain of the target file can be analyzed across layers, thereby performing cross-layer dependency analysis on the container image.

[0045] In one embodiment, the risk detection report includes at least one of the following: malicious file and its layer, description of malicious behavior and potential consequences, and remediation recommendations.

[0046] The risk detection report marks at least one malicious file among the multiple files included in the container image, indicates the potential risk of each malicious file, and facilitates the tracing and auditing of malicious files by associating them with their respective layers. For example, the malicious file is / tmp / X11-unix / update.sh, belonging to Layer 5 (Layer ID: sha256:abc123...).

[0047] The risk detection report includes the malicious behavior of the malicious file, explaining what it does, as well as a description of the potential consequences, outlining the harm it could cause. This helps users assess the severity of the risk posed by the malicious file. For example, if the malicious behavior involves initiating a TLS connection to 185.143.xx.xx:443, the potential consequence could be increased CPU resource consumption, leading to service degradation.

[0048] The risk detection report also includes remediation recommendations, such as measures to address malicious content, upgrade recommendations for dependencies, improvement recommendations to prevent recurrence, and recommendations to enhance detection capabilities.

[0049] This specification parses the hierarchical structure of a container image, obtaining file lists corresponding to multiple layers. Further, it compares each layer's file list layer by layer to accurately identify target files whose information has changed in at least two layers, and performs cross-layer tracking of these target files, constructing a record of information changes for each target file throughout the container image's lifecycle. Based on the information change records corresponding to at least one target file, it performs static scanning, dynamic behavior analysis, and cross-layer dependency analysis on the container image, generating a risk detection report indicating the malicious content included in the container image. This specification utilizes container layer parsing technology to comprehensively analyze the hierarchical structure of container images and the potential malicious content within layered files, offering broad coverage. It focuses on target files with changed information for risk detection, accurately locating risk sources and improving detection accuracy. Furthermore, this method is applicable to various container image formats and container images built using different methods, demonstrating good adaptability and enabling rapid discovery and response to potential risks within container images, thus improving container image security.

[0050] Please base on Figure 1 - Figure 3 The illustrated embodiments are also referred to. Figure 4 The illustrated embodiment. Figure 4 This is a schematic diagram illustrating an embodiment of the present specification for obtaining a file list corresponding to multiple layers. S102 includes the following steps: S102-1. Obtain the container image.

[0051] Container images can originate from public image repositories (such as Docker Hub) and be stored in the local Docker daemon's storage driver. Container images can also originate from private image repositories. Container images can also be imported from CI / CD platforms (such as GitLab CI, Jenkins, and GitHub Actions). This specification does not impose restrictions on the source of container images in the examples provided.

[0052] S102-2. Initialize the metadata of the container image and parse the hierarchical structure of the container image to obtain a list of files corresponding to multiple layers, as well as the hierarchical mapping relationship between the build files and the layers to which the files belong, and between the container images.

[0053] Initialize image metadata, such as image unique identifier (Image ID), tag, build timestamp, build tool information (such as Dockerfile summary or BuildKit metadata), base operating system type, and declared dependency list, and generate the basic mapping relationship of container images to prepare for subsequent layered loading.

[0054] Based on the layer order defined in the image's manifest file, each image layer is decompressed sequentially, and each image layer is loaded progressively from the bottom layer to the top layer. During the loading process, the original layer identifier (LayerDigest) and its sequence number in the container image are preserved to ensure the accuracy of the layer stacking order.

[0055] For each loaded image layer, its file system snapshots are traversed to extract structured metadata of the files and directories contained in that layer, such as file type, file size, permission mode, owner user and group (UID / GID), and last modified time (Mtime). Simultaneously, the incremental data introduced by this layer relative to adjacent layers is identified—that is, the set of files added, modified, or marked for deletion in this layer—as the difference content for that layer.

[0056] Based on the parsing results of each image layer, a file system tree structure is constructed for each image layer, and a file list corresponding to that layer is generated. The hierarchical mapping relationship between files and their respective layers and container images is constructed and persistently stored for subsequent steps such as layer-by-layer comparison, change tracking, static scanning, dynamic behavior analysis, and cross-layer dependency analysis.

[0057] In one embodiment, a container image is obtained and its integrity is verified. After the container image passes the integrity verification, the metadata of the container image is initialized and the hierarchical structure of the container image is parsed to obtain a list of files corresponding to multiple layers, as well as the hierarchical mapping relationship between the files and the layers to which the files belong and the container image.

[0058] After obtaining the container image, verify its integrity, that is, verify that the container image has not been illegally tampered with, replaced, or damaged during the process of building, distributing, and pulling, and ensure that its content is consistent with the original publisher's intention. Figure 1 Integrity verification includes digital signature verification (e.g., verifying whether the image container has a valid signature, whether it is signed by an authorized key, etc.), hash consistency verification (verifying that the pulled container image content is consistent with the specified digest), compliance verification (verifying whether the container image meets the security policies of an organization or industry), and may also include other forms of integrity verification.

[0059] In this embodiment, risk detection is performed only after the container image has passed integrity verification. This prevents the waste of computing resources caused by performing risk detection on invalid container images, and ensures that potential risks detected from complete container images are true and reliable, thereby improving the accuracy of risk detection.

[0060] In one embodiment, such as Figure 5The diagram shown is a flowchart illustrating a container image detection method provided in an embodiment of this specification. This method can be implemented using a computer program and can run on a container image detection device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application.

[0061] Specifically, the container image detection method includes: S202. Obtain the container image, parse the hierarchical structure of the container image, and obtain the file list corresponding to each layer.

[0062] See S102 above, which will not be repeated here.

[0063] S204. Based on the file list of each layer, compare the files layer by layer to determine the target file whose information has changed in at least two layers, and track the information change records of the target file across layers.

[0064] See S104 above; it will not be repeated here.

[0065] S206. Perform a static scan on at least one target file, identify at least one suspicious malicious file in the target file, and output a static scan report.

[0066] Static scanning is performed on target files whose information has changed in at least two layers. The final state of the target file within the container image can be determined based on its change history. If the target file is deleted in a subsequent layer (marked by a whiteout), scanning is unnecessary; otherwise, its raw byte content is extracted from the file system snapshot of the image layer to which the final state belongs, serving as input for static analysis.

[0067] Static scanning of a target file can include sensitive information detection, malicious code matching, executable file structure analysis, script semantic analysis, and file metadata anomaly detection. The results of these multiple detections are then combined to determine whether the target file is a suspicious malicious file. For example, if the target file contains multiple high-risk sensitive credentials, it is determined to be a suspicious malicious file.

[0068] The static scan report includes basic information about the suspicious malicious file and a list of corresponding security issues, specifically including the type of problem the suspicious malicious file has, the code snippet that matches the malicious content, the risk level, and so on.

[0069] In one embodiment, such as Figure 6 As shown, Figure 6 This is a schematic flowchart illustrating an embodiment of the present specification for outputting a static scan report. S206 includes the following steps: S206-1. Obtain a scanning strategy that matches the file type of the target file from the malicious signature database.

[0070] Based on the target file's extension, file header magic number, MIME type, and metadata information, the target file is classified into at least one of the following types: executable binary files (such as ELF, PE), script files (such as Shell scripts, Python scripts, JavaScript, PowerShell), and configuration or data files (such as YAML, JSON, XML). Scanning strategies matching the file type of the target file are obtained from the malicious signature database.

[0071] S206-2. Based on the scanning strategy, scan the target file to see if there are malicious features, and mark the target file with malicious features as a suspicious malicious file, and output a static scan report that marks the suspicious malicious file.

[0072] Based on different file types and scanning strategies, feature extraction and matching are performed on target files.

[0073] For example, for executable files, calculate their content hash value and perform an exact match with a malicious hash library. At the same time, parse their section structure, import table, and string constants, and apply YARA rules for semantic matching.

[0074] For example, for script files, the source code is parsed line by line, and a regular expression engine is used to detect whether it contains predefined malicious code patterns (such as reverse shell, mining commands, Base64 encoded payloads). At the same time, an abstract syntax tree (AST) is built to identify high-risk semantics such as dynamic execution and environment variable concatenation.

[0075] For example, for configuration files, check whether they contain inline execution instructions, abnormal network endpoints, or reference paths to untrusted resources.

[0076] After scanning the target file using the different scanning strategies described above, target files exhibiting malicious characteristics are identified as suspicious malicious files, and a static scan report marking the suspicious malicious files is output.

[0077] In this embodiment, the target file is accurately matched for malicious features based on file type, avoiding invalid scanning of irrelevant file types (such as plain text logs), significantly improving detection efficiency and accuracy, and ensuring that the static scanning results are traceable and operable.

[0078] S208. Run the suspicious malicious file in a simulated environment and perform dynamic behavior analysis to obtain a dynamic analysis report.

[0079] Build a lightweight, isolated simulation environment, such as creating a temporary container instance whose base image is the same as (or a compatible version of) the original container image to which the target file belongs. Run the target file marked as suspicious malicious during the static scanning phase in the simulation environment and start a monitoring mechanism to monitor the behavior of the suspicious malicious file, such as process behavior, file system operations, network activity, call sequences, etc.

[0080] The analysis process determines whether the behavior of suspicious malicious files matches malicious characteristics, including semantic analysis and threat assessment, resulting in a dynamic analysis report that includes behavioral data and analytical conclusions. This report may include a list of malicious behaviors of the suspicious files, threat assessment conclusions, a summary of behavioral evidence, and other information.

[0081] In one embodiment, a suspected malicious file is run in a simulated environment through an isolation sandbox, and the behavior logs generated by the suspected malicious file during runtime are obtained; the behavior logs are analyzed to see if there are any behaviors that match the characteristics of malicious behavior, and a dynamic analysis report is obtained.

[0082] Using an isolated sandbox environment, extracted suspicious malicious files are run in a simulated environment, capturing logs of their processes, network requests, file modifications, and other behaviors. Based on these logs, the behavior is dynamically analyzed to determine if it matches malicious characteristics, such as whether it attempts to connect to external networks (detecting whether it actively connects to non-transactional external IPs or domains) or generates covert communications. Behaviors matching these malicious characteristics are further labeled, and dynamic analysis reports for the suspicious malicious files are generated.

[0083] S210. Based on the information change records corresponding to at least one target file, perform cross-layer dependency analysis on multiple layers to obtain a dependency analysis report.

[0084] In one embodiment, based on the information change records corresponding to at least one target file, the system detects whether there are risks in the dependencies between multiple layers, assesses whether cross-layer behavior conforms to preset rules, and obtains a dependency analysis report.

[0085] Detect potential risks in dependencies between multiple layers. For example, missing dependencies in configuration files (dependencies declared in requirements.txt may not exist in the file system), or whether the executable depends on shared libraries (such as .so files) that are overridden in the underlying layers.

[0086] Based on information such as the change layer, change type, and previous / after status in the target file's information change record, the system assesses whether cross-layer behavior conforms to preset rules. Examples include: context recognition of dynamically generated malicious files (detecting malicious files dynamically generated through environment variables in the image layer), injection logic detection of multiple modifications to critical configuration files (e.g., multiple modifications to registry files may contain injection logic), analysis of virus behavior context, and identification of inconsistencies in cross-layer logic.

[0087] Based on the risk detection of dependencies between multiple layers and the evaluation results assessing whether cross-layer behavior complies with preset rules, a dependency analysis report for the container image is obtained. The dependency analysis report may include details of dependency risks, names and declaration locations of missing dependencies, broken shared library paths and required versions, and violations of cross-layer behavior rules.

[0088] S212. By combining the static scan report, dynamic analysis report, and dependency analysis report, a risk detection report is obtained.

[0089] The system analyzes the static scan report, dynamic analysis report, and dependency analysis report of the target file, correlates the corresponding information in these reports, marks whether the target file is a suspicious malicious file or a malicious file, includes malicious content or malicious behavior, and integrates the risk assessments of the target file from multiple reports to obtain a risk detection report.

[0090] This specification parses the hierarchical structure of a container image, obtaining file lists corresponding to multiple layers. Further, it compares each layer's file list layer by layer to accurately identify target files whose information has changed in at least two layers, and performs cross-layer tracking of these target files, constructing a record of information changes for each target file throughout the container image's lifecycle. Based on the information change records corresponding to at least one target file, it performs static scanning, dynamic behavior analysis, and cross-layer dependency analysis on the container image, generating a risk detection report indicating the malicious content included in the container image. This specification utilizes container layer parsing technology to comprehensively analyze the hierarchical structure of container images and the potential malicious content within layered files, offering broad coverage. It focuses on target files with changed information for risk detection, accurately locating risk sources and improving detection accuracy. Furthermore, this method is applicable to various container image formats and container images built using different methods, demonstrating good adaptability and enabling rapid discovery and response to potential risks within container images, thus improving container image security.

[0091] In one embodiment, such as Figure 7The diagram shown is a flowchart illustrating a container image detection method provided in an embodiment of this specification. This method can be implemented using a computer program and can run on a container image detection device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application.

[0092] Specifically, the container image detection method includes: S302. Obtain the container image, parse the hierarchical structure of the container image, and obtain a list of files corresponding to each layer.

[0093] See S102 above, which will not be repeated here.

[0094] S304. Based on the file list of the layer, construct the tree-like file index corresponding to the layer.

[0095] The hierarchical structure of the container image is parsed, and each image layer after decompression is traversed to extract file-level structural information, including file (such as file name, file type, size, and modification permissions) and directory metadata.

[0096] Starting from the root directory, this layer uses an N-ary tree data structure to organize the file system hierarchy. Each tree node corresponds to a file or directory, and the node attributes contain extracted metadata and file content. The parent-child relationship between nodes strictly follows the file system path hierarchy. For example, the node corresponding to the path / app / bin / run.sh is mounted under the / app node, and the / app node is mounted under the root node.

[0097] Tree-based file indexing enables the searching, traversal, or subtree extraction of any path in a short time, providing a foundation for efficient comparison and improving the efficiency of identifying target files.

[0098] S306. Compare the information of files with the same path in the tree file index layer by layer, and determine the file whose information has changed in at least two layers as the target file.

[0099] Based on the layer stacking order of the image container, the tree-structured file indexes of adjacent layers are loaded sequentially, and a global path mapping table is established to record the existence status and attributes of each path in each layer. File information under the same path is compared layer by layer to determine whether file information has changed.

[0100] In one embodiment, a tree-like file index corresponding to each layer is constructed based on the file list of each layer, and the hash value of each file is calculated based on its content. The hash values ​​of files with the same path in the tree-like file index are compared layer by layer to determine the target file as the file whose hash value has changed in at least two layers.

[0101] In a tree-structured file index, the target files that serve as nodes are read as follows: for regular files, their raw byte content is read and a content hash value (such as SHA256) is calculated to uniquely identify the file content; for directories or special files, the content field is set to empty or marked as non-content.

[0102] The hash values ​​of files with the same path in the tree-structured file index are compared layer by layer. When the hash value of a file changes, it indicates that the information of the file has changed in at least two layers.

[0103] This embodiment uses content hash value as the basis for change determination, rather than relying solely on file size or modification timestamp, to ensure the accuracy and anti-interference capability of change detection.

[0104] In one embodiment, the information of files with the same path in the tree file index is compared layer by layer to determine the target file as the file whose information has changed in at least two layers, and the change type of the target file is determined as addition, modification or deletion based on the information comparison results.

[0105] The system compares file information under the same path layer by layer. If path P exists in Layer N but not in Layer N+1, the target file corresponding to that path is determined to have been deleted in Layer i+1. If path P exists in both Layer N and Layer N+1, its file-level structure information is further compared, including the content hash value (e.g., SHA256). If they are different, the change is determined to be content modification. The system also compares the permission mode; if it changes from 0644 to 0755, it is determined to be a permission change. Furthermore, it compares file size, UID / GID, modification time, and other metadata information; any change in any field is considered a metadata change. If path P does not exist in Layer N but appears for the first time in Layer N+1, it is determined to be newly added.

[0106] S308, Cross-layer tracking of target file information change records.

[0107] It tracks changes to target files across multiple layers and summarizes information changes and change types that occur between multiple image layers to which the target file belongs. Information change records may include file path, image and layer sequence, layer index of each change, operation type, before and after status (permissions, hash, size, etc.), and final valid status (i.e., whether the target file exists and its attributes in the top-level image).

[0108] S310. Based on the information change records corresponding to at least one target file, perform static scanning, dynamic behavior analysis, and cross-layer dependency analysis on the container image to obtain a risk detection report.

[0109] See S106 above; it will not be repeated here.

[0110] This specification parses the hierarchical structure of a container image, obtaining file lists corresponding to multiple layers. Further, it compares each layer's file list layer by layer to accurately identify target files whose information has changed in at least two layers, and performs cross-layer tracking of these target files, constructing a record of information changes for each target file throughout the container image's lifecycle. Based on the information change records corresponding to at least one target file, it performs static scanning, dynamic behavior analysis, and cross-layer dependency analysis on the container image, generating a risk detection report indicating the malicious content included in the container image. This specification utilizes container layer parsing technology to comprehensively analyze the hierarchical structure of container images and the potential malicious content within layered files, offering broad coverage. It focuses on target files with changed information for risk detection, accurately locating risk sources and improving detection accuracy. Furthermore, this method is applicable to various container image formats and container images built using different methods, demonstrating good adaptability and enabling rapid discovery and response to potential risks within container images, thus improving container image security.

[0111] The following are embodiments of the apparatus described in this specification, which can be used to execute the embodiments of the methods described in this specification. For details not disclosed in the apparatus embodiments of this specification, please refer to the embodiments of the methods described in this specification.

[0112] Please see Figure 9 This diagram illustrates the structure of a container image detection device provided in an exemplary embodiment of this specification. The container image detection device can be implemented as all or part of a device through software, hardware, or a combination of both. The device includes a container acquisition module 401, a file recording module 402, and a risk analysis module 403.

[0113] The container acquisition module 401 is used to acquire a container image, parse the hierarchical structure of the container image, and obtain a file list corresponding to each of the multiple layers; wherein, the file list includes at least one file; The file recording module 402 is used to compare the file lists of each layer layer by layer to determine the target file whose information has changed in at least two layers, and to track the information change records of the target file across layers. The risk analysis module 403 is used to perform static scanning, dynamic behavior analysis, and cross-layer dependency analysis on the container image based on the information change records corresponding to at least one of the target files, and obtain a risk detection report.

[0114] In one embodiment, the risk analysis module 403 includes: A static scanning unit is configured to perform a static scan on at least one of the target files, identify at least one suspicious malicious file in the target files, and output a static scan report; The dynamic analysis unit is used to run the suspected malicious file in a simulated environment and perform dynamic behavior analysis to obtain a dynamic analysis report. A cross-layer analysis unit is used to perform cross-layer dependency analysis on multiple layers based on information change records corresponding to at least one of the target files, and to obtain a dependency analysis report. The report generation unit is used to combine the static scan report, the dynamic analysis report, and the dependency analysis report to obtain a risk detection report.

[0115] In one embodiment, the static scanning unit includes: The first static scanning subunit is used to obtain a scanning strategy that matches the file type of the target file from the malicious signature database; The second static scanning subunit is used to scan the target file for malicious features based on the scanning strategy, and to identify target files with malicious features as suspicious malicious files and output a static scanning report that marks the suspicious malicious files.

[0116] In one embodiment, the dynamic analysis unit includes: The first dynamic analysis subunit is used to run the suspected malicious file in a simulated environment through an isolation sandbox and to obtain the behavior logs generated by the suspected malicious file during runtime. The second dynamic analysis subunit is used to analyze whether there are behaviors in the behavior log that match the characteristics of malicious behavior, and to obtain a dynamic analysis report.

[0117] In one embodiment, the cross-layer analysis unit includes: The cross-layer analysis subunit is used to detect whether there is a risk in the dependency between multiple layers based on the information change records corresponding to at least one of the target files, and to evaluate whether the cross-layer behavior conforms to preset rules, so as to obtain a dependency analysis report.

[0118] In one embodiment, the file recording module 402 includes: An index building unit is used to build a tree-like file index corresponding to the layer based on the file list of the layer; The layer-by-layer comparison unit is used to compare the information of files with the same path in the tree-like file index layer by layer, and determine the file whose information has changed in at least two layers as the target file; A cross-layer tracking unit is used to track the information change records of the target file across layers.

[0119] In one embodiment, the index building unit includes: The index building subunit is used to build a tree-like file index corresponding to the layer based on the file list of the layer, and to calculate the hash value of the file based on the content of the file; Layer-by-layer comparison units include: By comparing the hash values ​​of files with the same path in the tree-like file index layer by layer, the file whose hash value changes in at least two of the layers is identified as the target file.

[0120] In one embodiment, the layer-by-layer comparison unit includes: The change confirmation subunit is used to compare the information of files with the same path in the tree file index layer by layer, determine the file whose information has changed in at least two layers as the target file, and determine the change type of the target file as addition, modification or deletion based on the information comparison results.

[0121] In one embodiment, the container acquisition module 401 includes: The container acquisition unit is used to acquire container images; The file list unit is used to initialize the metadata of the container image and parse the hierarchical structure of the container image to obtain a file list corresponding to multiple layers, and to construct a hierarchical mapping relationship between the file, the layer to which the file belongs, and the container image.

[0122] In one embodiment, the container acquisition unit includes: The first integrity verification subunit is used to obtain the container image and verify the integrity of the container image. The file list unit includes: The second integrity verification subunit is used to initialize the metadata of the container image and parse the hierarchical structure of the container image after determining that the container image has passed the integrity verification, to obtain a list of files corresponding to multiple layers, and to construct a hierarchical mapping relationship between the files, the layers to which the files belong, and the container image.

[0123] In one embodiment, the risk detection report includes at least one of the following: malicious file and the layer to which the malicious file belongs, description of malicious behavior and potential consequences, and remediation suggestions.

[0124] This specification parses the hierarchical structure of a container image, obtaining file lists corresponding to multiple layers. Further, it compares each layer's file list layer by layer to accurately identify target files whose information has changed in at least two layers, and performs cross-layer tracking of these target files, constructing a record of information changes for each target file throughout the container image's lifecycle. Based on the information change records corresponding to at least one target file, it performs static scanning, dynamic behavior analysis, and cross-layer dependency analysis on the container image, generating a risk detection report indicating the malicious content included in the container image. This specification utilizes container layer parsing technology to comprehensively analyze the hierarchical structure of container images and the potential malicious content within layered files, offering broad coverage. It focuses on target files with changed information for risk detection, accurately locating risk sources and improving detection accuracy. Furthermore, this method is applicable to various container image formats and container images built using different methods, demonstrating good adaptability and enabling rapid discovery and response to potential risks within container images, thus improving container image security.

[0125] It should be noted that the container image detection device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the container image detection method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the container image detection device and the container image detection method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0126] The example numbers in this specification are for descriptive purposes only and do not represent the superiority or inferiority of the examples.

[0127] This specification also provides a computer storage medium that can store multiple instructions adapted to be loaded and executed by a processor as described above. Figure 1 - Figure 7 The container image detection method of the illustrated embodiment can be found in the following documentation for a detailed execution process: Figure 1 - Figure 7 The specific details of the illustrated embodiments will not be elaborated here.

[0128] This specification also provides a computer program product that stores at least one instruction, which is loaded and executed by a processor as described above. Figure 1 - Figure 7 The container image detection method of the illustrated embodiment can be found in the following documentation for a detailed execution process: Figure 1 - Figure 7 The specific details of the illustrated embodiments will not be elaborated here.

[0129] Please see Figure 8 This document provides a schematic diagram of the structure of an electronic device as an embodiment of the present specification. Figure 8 As shown, the electronic device 500 may include: at least one processor 501, at least one network interface 504, user interface 503, memory 505, and at least one communication bus 502.

[0130] The communication bus 502 is used to enable communication between these components.

[0131] The user interface 503 may include a display screen and a camera. Optionally, the user interface 503 may also include a standard wired interface and a wireless interface.

[0132] The network interface 504 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0133] The processor 501 may include one or more processing cores. The processor 501 connects to various parts within the electronic device 500 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 505, and by calling data stored in the memory 505. Optionally, the processor 501 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLa). The processor 501 may integrate one or a combination of several of the following: a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 501 and may be implemented as a separate chip.

[0134] The memory 505 may include random access memory (RAM) or read-only memory. Optionally, the memory 505 may include a non-transitory computer-readable storage medium. The memory 505 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 505 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 505 may also be at least one storage device located remotely from the aforementioned processor 501. Figure 8 As shown, the memory 505, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a container image detection application.

[0135] exist Figure 8 In the illustrated electronic device 500, the user interface 503 is mainly used to provide an input interface for the user and to acquire user input data; while the processor 501 can be used to call the container image detection application stored in the memory 505 and specifically perform the following operations: Obtain the container image, parse the hierarchical structure of the container image, and obtain a file list corresponding to each layer; wherein, the file list includes at least one file; Based on the file list of each layer, compare layer by layer to determine the target file in which information has changed in at least two layers, and track the information change record of the target file across layers; Based on the information change records corresponding to at least one of the target files, static scanning, dynamic behavior analysis, and cross-layer dependency analysis are performed on the container image to obtain a risk detection report.

[0136] In one embodiment, processor 501 executes the static scanning, dynamic behavior analysis, and cross-layer dependency analysis of the container image based on the information change records corresponding to at least one of the target files, and obtains a risk detection report. Specifically, the following is performed: Perform a static scan on at least one of the target files, identify at least one suspicious malicious file in the target files, and output a static scan report; The suspected malicious file was run in a simulated environment and its dynamic behavior was analyzed to obtain a dynamic analysis report. Based on the information change records corresponding to at least one of the target files, cross-layer dependency analysis is performed on multiple layers to obtain a dependency analysis report. The risk detection report is obtained by combining the static scan report, the dynamic analysis report, and the dependency analysis report.

[0137] In one embodiment, processor 501 performs a static scan on at least one of the target files, identifies at least one suspicious malicious file among the target files, and outputs a static scan report. Specifically, the following steps are performed: Obtain a scanning strategy that matches the file type of the target file from the malicious signature database; Based on the scanning strategy, the target file is scanned for malicious features, and target files containing the malicious features are identified as suspicious malicious files, and a static scan report marking the suspicious malicious files is output.

[0138] In one embodiment, processor 501 executes the step of running the suspected malicious file in a simulated environment and performing dynamic behavior analysis to obtain a dynamic analysis report, specifically: The suspected malicious file was run in a simulated environment using an isolation sandbox, and the behavior logs generated by the suspected malicious file during runtime were obtained. The behavior logs are analyzed to determine if any behaviors match the characteristics of malicious behavior, and a dynamic analysis report is generated.

[0139] In one embodiment, processor 501 executes the method of performing cross-layer dependency analysis on multiple layers based on the information change records corresponding to at least one of the target files, and obtains a dependency analysis report. Specifically, the following steps are performed: Based on the information change records corresponding to at least one of the target files, detect whether there are risks in the dependencies between multiple layers, and assess whether cross-layer behavior conforms to preset rules, thereby obtaining a dependency analysis report.

[0140] In one embodiment, the processor 501 performs a layer-by-layer comparison based on the file lists of each layer to determine the target file whose information has changed in at least two layers, and tracks the information change records of the target file across layers. Specifically, the following is executed: Based on the file list of the layer, construct the tree-like file index corresponding to the layer; By comparing the information of files with the same path in the tree-like file index layer by layer, the file whose information has changed in at least two of the layers is identified as the target file; Track the information change records of the target file across layers.

[0141] In one embodiment, processor 501 executes the step of constructing a tree-like file index corresponding to the layer based on the file list of the layer, specifically by: Based on the file list of the layer, construct the tree-like file index corresponding to the layer, and calculate the hash value of the file based on the content of the file; Processor 501 performs the step-by-step comparison of information of files with the same path in the tree-like file index, and determines the file whose information has changed in at least two of the layers as the target file. Specifically, the following steps are performed: By comparing the hash values ​​of files with the same path in the tree-like file index layer by layer, the file whose hash value changes in at least two of the layers is identified as the target file.

[0142] In one embodiment, processor 501 performs the layer-by-layer comparison of information of files with the same path in the tree-like file index to determine the file whose information has changed in at least two layers as the target file, specifically by: By comparing the information of files with the same path in the tree-like file index layer by layer, the file whose information has changed in at least two layers is identified as the target file, and the change type of the target file is determined to be addition, modification or deletion based on the information comparison results.

[0143] In one embodiment, processor 501 executes the process of obtaining the container image, parsing the hierarchical structure of the container image, and obtaining a file list corresponding to each layer. Specifically, the following steps are performed: Obtain the container image; The metadata of the container image is initialized and the hierarchical structure of the container image is parsed to obtain a list of files corresponding to multiple layers, and to construct a hierarchical mapping relationship between the files, the layers to which the files belong, and the container image.

[0144] In one embodiment, processor 501 executes the process of obtaining the container image, specifically by: Obtain the container image and verify its integrity; The processor 501 executes the initialization of the container image's metadata and parses the container image's hierarchical structure to obtain a list of files corresponding to multiple layers, and constructs a hierarchical mapping relationship between the files, the layers to which the files belong, and the container image, and executes the specific steps. After confirming that the container image has passed the integrity verification, the metadata of the container image is initialized and the hierarchical structure of the container image is parsed to obtain a list of files corresponding to multiple layers, and to construct a hierarchical mapping relationship between the files, the layers to which the files belong, and the container image.

[0145] In one embodiment, the risk detection report includes at least one of the following: malicious file and the layer to which the malicious file belongs, description of malicious behavior and potential consequences, and remediation suggestions.

[0146] This specification parses the hierarchical structure of a container image, obtaining file lists corresponding to multiple layers. Further, it compares each layer's file list layer by layer to accurately identify target files whose information has changed in at least two layers, and performs cross-layer tracking of these target files, constructing a record of information changes for each target file throughout the container image's lifecycle. Based on the information change records corresponding to at least one target file, it performs static scanning, dynamic behavior analysis, and cross-layer dependency analysis on the container image, generating a risk detection report indicating the malicious content included in the container image. This specification utilizes container layer parsing technology to comprehensively analyze the hierarchical structure of container images and the potential malicious content within layered files, offering broad coverage. It focuses on target files with changed information for risk detection, accurately locating risk sources and improving detection accuracy. Furthermore, this method is applicable to various container image formats and container images built using different methods, demonstrating good adaptability and enabling rapid discovery and response to potential risks within container images, thus improving container image security.

[0147] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented. Each of the above methods can be executed by a computer program instructing related hardware. The program corresponding to the above methods can be stored in a computer-readable storage medium. When executed, the program can include the processes of the embodiments of the above methods. The storage medium of the electronic device 500 can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0148] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0149] The above-disclosed embodiments are merely preferred embodiments of this specification and should not be construed as limiting the scope of this specification. Therefore, any equivalent variations made in accordance with the claims of this specification shall still fall within the scope of this specification.

Claims

1. A method for detecting a container image, the method comprising: Obtain the container image, parse the hierarchical structure of the container image, and obtain a file list corresponding to each layer; wherein, the file list includes at least one file; Based on the file list of each layer, compare layer by layer to determine the target file in which information has changed in at least two layers, and track the information change record of the target file across layers; Based on the information change records corresponding to at least one of the target files, static scanning, dynamic behavior analysis, and cross-layer dependency analysis are performed on the container image to obtain a risk detection report.

2. The container image detection method according to claim 1, wherein the step of performing static scanning, dynamic behavior analysis, and cross-layer dependency analysis on the container image based on information change records corresponding to at least one of the target files to obtain a risk detection report includes: Perform a static scan on at least one of the target files, identify at least one suspicious malicious file in the target files, and output a static scan report; The suspected malicious file was run in a simulated environment and its dynamic behavior was analyzed to obtain a dynamic analysis report. Based on the information change records corresponding to at least one of the target files, cross-layer dependency analysis is performed on multiple layers to obtain a dependency analysis report. The risk detection report is obtained by combining the static scan report, the dynamic analysis report, and the dependency analysis report.

3. The container image detection method according to claim 2, wherein performing static scanning on at least one of the target files to identify at least one of the target files suspected malicious files, and outputting a static scan report, includes: Obtain a scanning strategy that matches the file type of the target file from the malicious signature database; Based on the scanning strategy, the target file is scanned for malicious features, and target files containing the malicious features are identified as suspicious malicious files, and a static scan report marking the suspicious malicious files is output.

4. The container image detection method according to claim 2, wherein running the suspicious malicious file in a simulated environment and performing dynamic behavior analysis to obtain a dynamic analysis report includes: The suspected malicious file was run in a simulated environment using an isolation sandbox, and the behavior logs generated by the suspected malicious file during runtime were obtained. The behavior logs are analyzed to determine if any behaviors match the characteristics of malicious behavior, and a dynamic analysis report is generated.

5. The container image detection method according to claim 2, wherein the step of performing cross-layer dependency analysis on multiple layers based on information change records corresponding to at least one of the target files to obtain a dependency analysis report includes: Based on the information change records corresponding to at least one of the target files, detect whether there are risks in the dependencies between the multiple layers, and assess whether the cross-layer behavior conforms to preset rules, to obtain a dependency analysis report.

6. The container image detection method according to claim 1, wherein the step of comparing the file lists of each layer layer by layer to determine the target file whose information has changed in at least two layers, and tracking the information change records of the target file across layers, includes: Based on the file list of the layer, construct the tree-like file index corresponding to the layer; By comparing the information of files with the same path in the tree-like file index layer by layer, the file whose information has changed in at least two of the layers is identified as the target file; Track the information change records of the target file across layers.

7. The container image detection method according to claim 6, wherein constructing a tree-like file index corresponding to the layer based on the file list of the layer includes: Based on the file list of the layer, construct the tree-like file index corresponding to the layer, and calculate the hash value of the file based on the content of the file; The step of comparing the information of files with the same path in the tree-structured file index layer by layer to determine the file whose information has changed in at least two layers is the target file includes: By comparing the hash values ​​of files with the same path in the tree-like file index layer by layer, the file whose hash value changes in at least two of the layers is identified as the target file.

8. The container image detection method according to claim 6, wherein the step of comparing the information of files with the same path in the tree file index layer by layer to determine the file whose information has changed in at least two layers is the target file includes: By comparing the information of files with the same path in the tree-like file index layer by layer, the file whose information has changed in at least two layers is identified as the target file, and the change type of the target file is determined to be addition, modification or deletion based on the information comparison results.

9. The container image detection method according to claim 1, wherein obtaining the container image and parsing the hierarchical structure of the container image to obtain a file list corresponding to multiple layers respectively includes: Obtain the container image; The metadata of the container image is initialized and the hierarchical structure of the container image is parsed to obtain a list of files corresponding to multiple layers, and to construct a hierarchical mapping relationship between the files, the layers to which the files belong, and the container image.

10. The container image detection method according to claim 9, wherein obtaining the container image includes: Obtain the container image and verify its integrity; The process of initializing the metadata of the container image and parsing the hierarchical structure of the container image to obtain a list of files corresponding to multiple layers, and constructing a hierarchical mapping relationship between the files, the layers to which the files belong, and the container image, includes: After confirming that the container image has passed the integrity verification, the metadata of the container image is initialized and the hierarchical structure of the container image is parsed to obtain a list of files corresponding to multiple layers, and to construct a hierarchical mapping relationship between the files, the layers to which the files belong, and the container image.

11. The container image detection method according to claim 1, wherein the risk detection report includes at least one of the following: malicious file and the layer to which the malicious file belongs, description of malicious behavior and potential consequences, and remediation suggestions.

12. A container mirror detection device, the device comprising: The container acquisition module is used to acquire a container image, parse the hierarchical structure of the container image, and obtain a file list corresponding to each of the multiple layers; wherein, the file list includes at least one file; The file recording module is used to compare the file lists of each layer layer by layer to determine the target file whose information has changed in at least two layers, and to track the information change records of the target file across layers. The risk analysis module is used to perform static scanning, dynamic behavior analysis, and cross-layer dependency analysis on the container image based on the information change records corresponding to at least one of the target files, and to obtain a risk detection report.

13. A computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the method steps of any one of claims 1 to 11.

14. A computer program product storing a plurality of instructions adapted for loading by a processor and executing the method steps of any one of claims 1 to 11.

15. An electronic device, comprising: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed the method steps as claimed in any one of claims 1 to 11.

Images