Methods, apparatus, electronic devices and storage media for black-box API testing of containers

Abstract

This disclosure provides a method, apparatus, electronic device, and storage medium for black-box API detection of containers. The method for black-box API detection of containers includes: acquiring feature information of a first container, the first container being the container to be detected; inputting the feature information of the first container into a preset model to generate a detection strategy for the first container, wherein the preset model is generated based on reference information, the reference information including: feature information of a second container, and historical detection results of the second container corresponding to the feature information of the second container; the number of second containers is one or more, and the detection strategy for the first container includes: reusable historical detection results of the first container; and performing black-box API detection on the first container according to the detection strategy. This disclosure can improve detection speed.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for black-box API detection of containers. Background Technology

[0002] With the widespread adoption of cloud computing and microservice architectures, container technology has become a primary technology for modern application deployment. The lightweight and dynamic nature of containers enhances deployment flexibility but also presents challenges for security monitoring. Traditional container black-box API (Application Interface) detection employs traversal and response-based methods, which suffer from low efficiency and are often unsatisfactory. Summary of the Invention

[0003] This disclosure provides a method, apparatus, electronic device, and storage medium for black-box API detection of containers.

[0004] The following technical solution is adopted in this disclosure.

[0005] In some embodiments, this disclosure provides a method for detecting the black-box API of a container, including:

[0006] Obtain feature information of the first container, which is the container to be detected;

[0007] The feature information of the first container is input into a preset model to generate a detection strategy for the first container. The preset model is generated based on reference information, which includes: feature information of the second container and historical detection results of the second container corresponding to the feature information of the second container. The number of the second containers is one or more, and the detection strategy of the first container includes: reusable historical detection results of the first container.

[0008] The first container is subjected to black-box API detection according to the detection strategy.

[0009] In some embodiments, this disclosure provides a black-box API detection device for a container, comprising:

[0010] The acquisition unit acquires feature information of the first container, which is the container to be detected.

[0011] The control unit is configured to input the feature information of the first container into a preset model to generate a detection strategy for the first container. The preset model is generated based on reference information, which includes: feature information of the second container and historical detection results of the second container corresponding to the feature information of the second container. The number of the second containers is one or more, and the detection strategy for the first container includes: reusable historical detection results of the first container.

[0012] The control unit is further configured to perform black-box API detection on the first container according to the detection strategy.

[0013] In some embodiments, this disclosure provides an electronic device, including: at least one memory and at least one processor;

[0014] The memory is used to store program code, and the processor is used to call the program code stored in the memory to execute the above method.

[0015] In some embodiments, this disclosure provides a computer-readable storage medium for storing program code that, when run by a processor, causes the processor to perform the methods described above.

[0016] The container black-box API detection method provided in this embodiment of the present disclosure has the advantage of reusing detection results of the same image because the image has static characteristics and the container has multiple copies, so multiple container copies of the same image can be reused. This can reduce the content that needs to be detected in the first container and improve the detection speed by reusing existing historical detection results. Attached Figure Description

[0017] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0018] Figure 1 This is a flowchart of a black-box API detection method for containers according to an embodiment of this disclosure.

[0019] Figure 2 This is a schematic diagram of a black-box API detection method for containers according to an embodiment of this disclosure.

[0020] Figure 3 This is a schematic diagram illustrating the generation of feature information according to an embodiment of this disclosure.

[0021] Figure 4 This is a schematic diagram illustrating the generation of a vulnerability report according to an embodiment of this disclosure.

[0022] Figure 5 This is a schematic diagram illustrating black-box API detection of a container according to an embodiment of this disclosure.

[0023] Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure. Detailed Implementation

[0024] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0025] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.

[0026] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0027] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0028] It is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.

[0029] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0030] It should be understood that the various steps described in the method embodiments of this disclosure can be performed in sequence and / or in parallel. Furthermore, method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0031] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0032] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0033] It should be noted that the use of the word "a" in this disclosure is illustrative rather than restrictive, and those skilled in the art should understand that it should be understood as "one or more" unless otherwise expressly indicated in the context.

[0034] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0035] The solutions provided by the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings.

[0036] Definitions:

[0037] Image: An image is a special file system that contains all the code, runtime libraries, environment variables, and configuration information required to run a container. An image does not contain any dynamic data, and its contents are not changed after it is built; it consists of static files.

[0038] Image layers: Image layers are incremental file system changes that make up an image. Each layer represents a state or operation in the image building process, and they are stacked together to form a complete image.

[0039] Containers: Containers are running instances created from images using operating system-level virtualization technology. They have independent file systems, networks, and process spaces, allowing applications to run in isolated environments. One image can launch multiple containers, and each container can be started, stopped, paused, resumed, and deleted.

[0040] Container load: When a container is running, it also depends on the environment such as processor, memory, disk, and network. These environments and the container as a whole are called container load.

[0041] Black-box API testing of containers is a professional security testing method that simulates the behavior of real users or clients to assess the security of APIs without needing to understand their internal logic and source code details. This process involves constructing and sending designed HTTP requests to interact with the web application, encompassing normal, abnormal, and even potentially malicious inputs to comprehensively test the API's responses and behavior. The testing tool accurately captures and analyzes the API's responses to requests, interpreting key information such as HTTP status codes, response headers, and response bodies. Through in-depth analysis of this response data, the tool can accurately identify potential security vulnerabilities in the API, including but not limited to information leakage, unauthorized access, and insufficient input validation. The tool typically employs traversal and probing methods, such as detecting entire IP address ranges, port ranges, or using known API paths and parameter patterns to identify potential API interfaces.

[0042] Traditional container black-box API detection employs traversal and response-based methods, neglecting the characteristics of container technology and suffering from resource intensity, low efficiency, long processing times, and low detection accuracy. In some embodiments of this disclosure, by integrating container feature information, static vulnerability analysis results, and black-box API detection rule bases, and leveraging the multi-copy nature of containers and the immutability of images, second containers and second images are pre-collected for vulnerability detection. Based on this data, a rule model is constructed to identify security risks and improve detection speed during actual black-box detection.

[0043] This disclosure proposes a black-box API detection method for containerized environments in some embodiments. It leverages the multi-copy mechanism of containers and the immutability of images to construct feature information by acquiring and analyzing metadata of a second container and a second image. Then, it utilizes the immutability of images for efficient static detection. Next, it combines the feature information, vulnerability detection, and a rule base for black-box API detection to obtain a preset model. Based on this preset model, it customizes a specific API detection strategy (target strategy) for the first container and initiates targeted detection. The methods in some embodiments of this disclosure utilize the multi-copy mechanism of containers and the immutability of images to accelerate the detection process and enhance detection accuracy. The solutions in this disclosure are not effective under host load because the host is a mutable asset that is prone to change during runtime, making detection results unusable. However, this problem does not exist in container scenarios. Images are immutable, and detection results from container copies of the same image can be reused, which is an advantage in container scenarios.

[0044] like Figure 1 As shown, Figure 1 and Figure 2 This is a flowchart of a black-box detection method according to an embodiment of the present disclosure, which includes the following steps.

[0045] S11. Obtain the feature information of the first container.

[0046] In some embodiments, the first container is the container to be detected, which is an example generated based on the first image. An application can run on the first container. The feature information typically includes multiple features; specifically, the feature information of the first container includes, for example, various element locations (Repo, Tag, ImageID, etc.), runtime environment (container ID, image hash, etc.), and network configuration (IP address, open ports, service protocols, etc.).

[0047] S12. Input the feature information of the first container into a preset model to generate a detection strategy for the first container.

[0048] In some embodiments, the preset model is generated based on reference information, which includes: feature information of the second container and historical detection results of the second container corresponding to the feature information of the second container. There may be one or more second containers, and the detection strategy for the first container includes: reusable historical detection results of the first container. Historical detection results may include, for example, the detection results of historical black-box APIs of the second container and the detection results of vulnerability detection of the second image. Historical black-box API detection results are the detection results obtained from previous black-box API detection of the second container. Vulnerability detection can be the analysis of one or both of static software information and configuration information to determine potential vulnerabilities or risks. In some embodiments, the second container is a container, and there may be one or more of them; typically, there are multiple second containers. The second image is an image, and there may be one or more of them; each second image may be different, or there may be identical second images. Any second container may be an instance generated based on a certain second image. The vulnerability detection results of the second container describe its potential risks, such as the number of potential vulnerabilities, the configuration information risk, and the degree of configuration information risk. The black-box API detection rule base includes one or more black-box API detection rule sets, which describe the rules used when performing black-box API detection. Historical black-box API detection results are the results obtained from previous black-box API detection of the second container.

[0049] In some embodiments, a preset model is used to determine potential risks based on feature information and generate corresponding detection strategies. After obtaining the reference information, a mapping relationship can be established between feature information and vulnerability detection results, a black-box API detection rule base, and historical black-box API detection results. This establishes the association between container feature information and potential risks. Based on these potential risks, a detection strategy (API detection strategy) can be customized, thus establishing the relationship between feature information and the detection strategy. Therefore, when a feature is input into the preset model, the detection strategy corresponding to that risk fingerprint can be obtained. Potential risks include, for example, one or more of vulnerabilities and configuration information risks. Because of the pre-obtained correspondence between the feature information of the second container and its historical detection results, after obtaining the feature information of the first container, the preset model can first determine if there are any historical detection results that can be reused for the first container. If so, when performing black-box API detection on the first container, these historical detection results can be reused, thus avoiding detection of the content in the first container corresponding to those historical detection results, thereby reducing detection time and improving detection speed.

[0050] S13. Perform black-box API detection on the first container according to the detection strategy.

[0051] In some embodiments, the first container may be a container instance generated from the same or partially the same image as the second container. For example, a second container and a first container may be instances of containers from the same image, or the first image on which the first container is based and the second image on which the second container is based may have a build dependency relationship and may have partially identical image layers. The first container may have completely identical feature information to a second container, so the historical black-box API detection results of the second container can be directly reused, thus eliminating the need for detection of the first container. The first container can also share some of the same feature information as a second container. The historical detection results of the second container corresponding to the shared feature information can be reused, eliminating the need to detect the content corresponding to that shared feature information in the first container. For example, if the first image has image layers 1, 2, and 3, and the second image is built based on the first image, having image layers 1, 2, 3, 4, and 5, then the historical detection results of the second container regarding image layers 1, 2, and 3 can be reused. For instance, if the historical detection results include vulnerability detection results, then the vulnerability detection results for image layers 1, 2, and 3 can be directly reused without needing to perform vulnerability detection on the duplicate image layers in the first image. Similarly, historical detection results including historical black-box API detection results can also reuse the parts corresponding to image layers 1, 2, and 3 in the historical black-box API detection. Feature information can be a set of container features. The detection strategy is a detection method designed for containers. In this embodiment, the historical detection results of the second container are reused in the preset model, so as to avoid repetitive work when performing black-box API detection on the first container, thereby accelerating the detection as a whole.

[0052] In some embodiments of this disclosure, because images have static characteristics, detection results for the same image can be reused; and containers have multiple copy characteristics, multiple container copies of the same image can be reused. Therefore, before detecting the first container, reusable historical detection results are determined first. The portion of the reusable historical detection results corresponding to the first container does not need to be re-detected, thus improving detection speed. In traditional host load scenarios, because the host is variable, detection results cannot be reused.

[0053] In some embodiments of this disclosure, the historical detection results of the second container include: historical black-box API detection results of the second container. In some embodiments of this disclosure, the second container is built from a second image, and the second container is an instance of the second image; the historical detection results of the second container include: vulnerability detection results of the second image.

[0054] In some embodiments, before performing black-box API testing on a container (e.g., a first container or a second container), a static vulnerability test can be performed on the container. This allows for the analysis of potential risks in application and configuration information, enabling the preparation of targeted attack examples for these potential risks during the black-box API testing. If the historical test results include vulnerability test results from the second image, then when performing vulnerability testing on the first container, it can be determined whether there are reusable vulnerability test results. If so, these results are reused, thereby reducing the portion of the first container that needs vulnerability testing. Similarly, if the historical test results include historical black-box API test results from the second container, reusable results are reused, further reducing the portion of the first container that needs black-box API testing.

[0055] In some embodiments of this disclosure, the feature information of the first container is input into a preset model to generate a detection strategy for the first container, including performing the following operations in the preset model: in response to the feature information of the second container and the feature information of the first container showing that the second container and the first container are instances built from the same image, the reusable historical detection results are determined to include: the historical detection results of the second container.

[0056] In some embodiments, historical detection results are reused to improve detection speed. When two containers are built from the same image, the historical detection results of the second container (e.g., historical black-box API detection results) can be directly reused because the image is immutable and the container has a multi-copy mechanism; the images that both depend on are necessarily identical, and they are simply two instances. Therefore, when performing black-box API detection on the first container, the historical detection results of the second container can be completely reused, thus eliminating the need to perform detection on the first container.

[0057] In some embodiments of this disclosure, the feature information of the first container is input into a preset model to generate a detection strategy for the first container, including performing the following operations in the preset model: in response to the feature information of the second container and the feature information of the first container displaying that the first container is built from a first image, the second container is built from a second image, and the first image and the second image have a build dependency relationship, the historical detection results that the first container can be reused include: the part of the image layer in the second image that is the same as the first image in the historical detection results.

[0058] In some embodiments, the first image and the second image have a build dependency relationship, meaning the first image can be built based on the second image, or vice versa. In this case, they have some identical image layers. For example, the first image includes image layers 1 to 5, and the second image includes image layers 1 to 3. In this case, the historical detection results (e.g., vulnerability detection results) of image layers 1 to 3 can be directly reused, thereby avoiding the repeated execution of the same detection on image layers 1 to 3 in the first image.

[0059] In some embodiments of this disclosure, the feature information of the first container is input into a preset model to generate a detection strategy for the first container, including performing the following operations in the preset model: after determining the reusable historical detection results of the first container, determining the vulnerability detection results of the first image; and determining the detection strategy for the first container based on the vulnerability detection results of the first image.

[0060] In some embodiments, in a preset model, the vulnerability detection results of the first image are obtained. When obtaining the vulnerability detection results of the first image, reusable historical vulnerability detection results can be obtained from reusable historical detection results. Vulnerability detection is only performed on the parts of the first image that do not have reusable historical vulnerability detection results. For example, if the first image includes static layers 1 to 5, and static layers 1 to 3 already have reusable historical vulnerability detection results, then vulnerability detection only needs to be performed on static layers 4 and 5 to obtain the vulnerability detection results of the first image. By performing vulnerability detection, attack examples can be prepared for potential risks, avoiding the blind use of attack examples. Reducing the number of attack examples can further improve the detection speed.

[0061] In some embodiments of this disclosure, the reference information further includes: a black-box API detection rule base; the black-box API detection rule base includes: black-box API detection rules; the detection strategy further includes: the black-box API detection rules used when performing black-box API detection on the first container.

[0062] In some embodiments, black-box API detection rules can describe the methods used when performing black-box API detection on a container. For example, the Log4j vulnerability, also known as Log4Shell, which surfaced in 2021, is a remote code execution vulnerability in Apache Log4j 2. Attackers can trigger Log4j to load classes from an external LDAP server and execute malicious code by constructing specific input data (usually strings from network log messages). Black-box API detection rules can include: when a Log4j package is found, attempting to detect whether it has the aforementioned Log4j vulnerability. Because the characteristic information of the first container is obtained, it can be determined whether it meets the conditions for using black-box API detection rules based on the first container's characteristic information. If the conditions are met, the corresponding black-box API detection rules can be applied. The detection strategy records the black-box API detection rules that meet the conditions, so that these met black-box API detection rules are used when performing black-box API detection on the first container.

[0063] In some embodiments of this disclosure, the feature information of the first container or the second container is obtained in the following manner: obtaining the metadata of the target container and the metadata of the target image, wherein the target container is the first container or the second container, and the target container is built from the target image, that is, the target image is the first image or the second image; constructing feature association relationships based on the metadata of the target container and the metadata of the target image; and generating feature information of the target container based on the feature association relationships.

[0064] In some embodiments, such as Figure 3As shown, during the generation of feature information, the Kubernetes API (e.g., using the Go client library k8s.io / client-go) and Docker SDK (e.g., Phthon's docker library) can be used to collect metadata about the target container and target image. Metadata includes, but is not limited to, repository address (repo), tags, image ID, software list, active processes, open ports, and running applications. Metadata reflects the features. Taking obtaining software packages and running applications as examples, when obtaining software packages, the method for package collection needs to be determined based on the characteristics of the target image. Specifically, for images based on operating systems such as Debian or Ubuntu, the package list file in the / var / lib / apt / lists / directory can be checked; for RPM-based images, the database file in the / var / lib / rpm / directory can be checked. For collecting language packs within the software package, the method needs to be determined based on the characteristics of the language. For example, the Java language can identify language packs through file extensions (e.g., jar, war) and use the Manifest file or the jar command to obtain version information. For Go packages, identification can be done by searching for executable files or static libraries. However, since compiled Go binaries do not contain version information, version identification may require combining other methods (such as Docker tags or build history). When obtaining running applications, one or more methods can be used, including process detection, port listening, and file inspection. Process detection identifies running applications by examining the process list within the target container. For common applications, identification can be based on process name or command-line arguments. Port listening identifies running applications by detecting the ports listened to by the target container and comparing them with the default ports of known applications. File inspection examines specific files or directories within the target container (such as application configuration files or log files) to confirm the existence and identification of the application. To improve the accuracy of application identification, the results of process detection, port listening, and file inspection can be combined to comprehensively determine the application within the target container. After obtaining the metadata of the target container and target image, the metadata can be cleaned and converted into a unified data model using standardized field formats, thereby generating characteristics such as target container, target image, process, package, and application. In some embodiments, these features are calculated and associated to construct a multi-level feature association graph with the target container as the node and one or more of the target image, software package, application, and configuration information as attributes. The attributes associated with the target container can be known through the feature association.In some embodiments, the feature association relationships include one or more of the following: instantiation relationship between target image and target container, replication relationship between different target containers, build relationship between different target images, application-port mapping relationship, and target container-application mapping relationship. The instantiation relationship between target container and target image can be a mapping constructed by analyzing the image ID and container instance; if one container is an instance of another image, then they have an instantiation relationship. If multiple containers are instances of the same image, then the multiple containers have a replication relationship. If multiple images are built based on the same base image, then the multiple images have a build relationship; images built based on the same base image can be identified by comparing the image hierarchy. The application-port mapping relationship can characterize the ports used or possessed by the application. The target container-application mapping relationship can characterize the application running in the target container; the mapping relationship between target container and application can be established based on process, port, and application identifier. After the feature association relationship is created, the feature information of the target container is completed based on this feature association relationship. The feature information may include, but is not limited to, one or more of image hashes and configuration information. Based on the target container's feature information, preparation is made for the subsequent generation of a preset model. Since feature information is created based on feature relationships, attributes related to the feature information can be obtained, such as related images, software packages, applications, and configuration information. These attributes can help identify potential risks associated with containers possessing that feature information, such as outdated software packages or unauthorized open ports. The target container's feature information integrates one or more of the following: target container metadata, target image metadata (image ID, etc.), runtime environment (container ID, image hash value), application fingerprint (based on application metadata and configuration information), and network configuration (IP address, open ports, service protocols). This achieves multi-dimensional information integration. Furthermore, the target container's feature information is updated periodically or in real-time. For example, a periodic check is designed to periodically check for changes in metadata; if changes occur, the target container's feature information is recalculated to ensure that the feature information remains up-to-date. In some embodiments, industry-standard algorithms (such as SHA-256) can be used to encrypt feature relationships, generating irreversible feature information to ensure data security and privacy protection.

[0065] In some embodiments of this disclosure, the vulnerability detection results of the second image are obtained through at least one of the following methods: Method 1: A layered static vulnerability detection method is used to perform vulnerability detection on each layer of the second image, and the vulnerability detection results of the second image are generated based on the vulnerability detection results. Method 2: A layered static vulnerability detection method is used to perform configuration information risk detection on each layer of the second image, and the vulnerability detection results of the second image are generated based on the configuration information risk detection results.

[0066] In some embodiments, reference is made to Figure 4 When performing vulnerability testing on the second image, the detection strategy to be used can be determined first. Considering the immutable nature of the image, this embodiment adopts a layered static vulnerability detection strategy, performing layer-by-layer vulnerability and configuration information risk detection on each layer of the second image. Vulnerability testing on the second image can be performed periodically at regular intervals. If the second image has previously undergone vulnerability testing, newly added or modified image layers can be marked during the next vulnerability test, thus focusing vulnerability testing only on newly added or modified image layers, significantly reducing workload. After performing vulnerability and configuration risk detection on the second image, the vulnerabilities in the second image and the risks present in the configuration information can be obtained. Combining these two results yields the vulnerability detection outcome.

[0067] In some embodiments of this disclosure, the vulnerability detection results of the second image are obtained through at least one of the following methods: Method 1: Obtain the metadata of the second image, and obtain software information from the metadata of the second image; load a vulnerability rule base, which includes known vulnerabilities and corresponding software information; perform vulnerability detection based on the software information of the second image and the vulnerability rule base; generate the vulnerability detection results of the second image based on the vulnerability detection results. Method 2: Obtain the metadata of the second image, and obtain configuration information from the metadata of the second image; load a configuration baseline rule base, which includes expected configuration information; perform configuration information risk detection based on the configuration information of the second image and the configuration baseline rule base; generate the vulnerability detection results of the second image based on the configuration information risk detection results.

[0068] In some embodiments, when performing vulnerability detection on the second image, the metadata of the second image is first obtained, including, for example, the second container name or second image name, version number, operating system type, etc. Software information and configuration information are then extracted from this metadata. The software information may include system software information and application information. The configuration information may include various configuration items and their values. The vulnerability rule base may include known vulnerabilities of various system software and various applications. By comparing the software information of the second image with the vulnerability rule base, the potential vulnerabilities of the second image can be identified as the vulnerability detection result. The configuration baseline rule base may contain expected configuration information, which may include expected values ​​for configuration items. By comparing the expected configuration information with the actual configuration information of the second image, and determining whether they are the same, potential problems in the configuration information can be identified (e.g., different parts can be considered as having risks), and the severity of these problems can be assessed as the risk detection result for the configuration information. After obtaining the detection results of vulnerability detection and configuration information risk detection, the vulnerability detection results of the second image can be generated. These results may include information about the second image, such as: vulnerability ID, the ID of the risky configuration information, the severity of the vulnerability, and the severity of the risky configuration information. The vulnerability detection results can be used to determine the detection strategy for black-box API detection of the first container. The preset model can identify the characteristic information of the first container to determine the corresponding vulnerability detection results. Based on these results, vulnerabilities and configuration risks in the first container are identified, and attacks are launched against these vulnerabilities and configuration risks, thereby reducing the number of attack examples.

[0069] In some embodiments of this disclosure, when performing vulnerability checks on the same second image again, only the parts of the vulnerability rule base that have changed compared to the previous vulnerability check of the second image are loaded when loading the vulnerability rule base. In some embodiments, when performing vulnerability checks on the same second image again, only the parts of the configuration baseline rule base that have changed compared to the previous vulnerability check of the second image are loaded when loading the configuration baseline rule base. In some embodiments, the second image may undergo multiple vulnerability checks; for example, a detection period can be set to periodically perform vulnerability checks on the second container and the second image. During non-first vulnerability checks on the second image, when loading the vulnerability rule base, only the parts that have changed compared to the previous vulnerability check of the second image can be loaded. This allows the previous detection results to be reused for the unchanged parts. This reduces the need to repeatedly perform vulnerability checks. Similarly, for the configuration baseline rule base, during non-first vulnerability checks on the second image, only the parts that have changed compared to the previous vulnerability check of the second image are loaded.

[0070] In some embodiments of this disclosure, during the process of generating a preset model based on reference information, association logic is established to perform security assessment on the API of the first container, thereby optimizing the detection strategy, improving the speed and accuracy of black-box API detection, reducing repeated detection of known secure APIs, and saving computing resources. Specifically, the preset model includes at least one of the following: the association between feature information and the black-box API detection rule base, which is used to determine the black-box API detection rules in the black-box API detection rule base to which the feature information applies; the dependency relationship of the black-box API detection rules in the black-box API detection rule base, which is used to determine the execution order of the black-box API detection rules; the API list corresponding to the vulnerability detection results, which is used to indicate the priority detection APIs associated with the vulnerability detection results; the optimization rules of the black-box API detection rule base, which is used to adjust the black-box API detection rules in the black-box API detection rule base according to the configuration information; the API risk classification rules, which are used to classify the risk of APIs based on the historical black-box API detection results in the historical detection results; the historical black-box API detection result reuse rules, which are used to reuse the historical black-box API detection results of APIs when an API that has not changed is identified; and the association between vulnerabilities and the black-box API detection rule base, which is used to determine the black-box API detection rules corresponding to vulnerabilities.

[0071] In some embodiments, a pre-defined model establishes an association between feature information and a black-box API detection rule base. Upon obtaining a feature, the pre-defined model can look up its associated attributes (e.g., associated images, software packages, applications, configuration information). Then, based on these associated attributes, it determines the black-box API detection rule base from the black-box API detection rule base. The determined black-box API detection rule base can then serve as the recommended detection strategy for the container corresponding to that feature. For example, if the container's associated attributes indicate that it is running a Tomcat application and identify its version, configuration files, dependencies, etc., the pre-defined model will automatically match the Tomcat-related black-box API detection rule base, such as specific HTTP response checks or default management interface access attempts, thereby ensuring targeted detection.

[0072] In some embodiments, some or all of the black-box API detection rules have dependencies on each other. For example, rule 2 can only be executed after rule 1 has been executed, and the result of rule 2 determines whether rule 3 or rule 4 is executed. The execution order of the black-box API detection rules can be determined through these dependencies.

[0073] In some embodiments, the API list corresponding to the vulnerability detection results includes priority detection APIs with vulnerabilities or configuration information risks. These APIs represent the APIs that should be prioritized for detection when these vulnerabilities or configuration information risks are present. For example, if a vulnerability is found in a container during vulnerability detection, a preset model will mark the APIs affected by the vulnerability so that these APIs will be prioritized for detection during black-box API detection. If the feature information of a first container is the same as that of a second container, and the API list corresponding to the vulnerability detection results of the second container can be obtained, the detection strategy will instruct that the API list corresponding to the vulnerability detection results of the second container be prioritized for detection. In some embodiments, the optimization rules of the black-box API detection rule base may limit how to adjust the black-box API detection rule base according to the configuration information. For example, if the configuration information limits the listening port, the black-box API detection rule base will be adjusted to send requests only to that listening port. By considering the configuration information when detecting container black-box APIs, unnecessary detections can be reduced. API risk grading rules can be used to rate the risk of APIs based on historical black-box API detection results. For example, if an API shows an attack frequency higher than a first preset frequency in historical black-box API detection results, its risk rating can be increased; if an API shows an attack frequency lower than a second preset frequency, its risk rating can be decreased. Thus, when performing black-box API detection on container APIs, the detection depth can be determined based on the API's risk rating. For example, deep detection can be used for APIs with high risk ratings, while lightweight or delayed detection can be used for APIs with low risk ratings. In some embodiments, historical black-box API detection results use rules to describe the reuse criteria for black-box API detection results. For example, for APIs and configuration information that have not changed, the preset model can use the previous historical black-box API detection results for that API to avoid unnecessary duplicate detections. For instance, if an API has not changed since the first black-box API detection, it can be skipped during the second black-box API detection, saving resources. In some embodiments, the association between vulnerabilities and black-box API detection rule bases can be used to determine the black-box API detection rule base corresponding to the vulnerability. When a vulnerability is found in a container, a preset model searches for the black-box API detection rule base associated with the vulnerability, thereby ensuring coverage of potential dangers.

[0074] In some embodiments of this disclosure, the detection strategy includes: a risk rating of the API of the first container. Black-box API detection of the first container according to the detection strategy includes: determining the detection priority and / or detection depth of the API of the first container based on the risk rating of the API of the first container; in some embodiments, such as Figure 5In the rule-based filtering section, when performing black-box API testing on the first container, high-risk APIs undergo in-depth testing, while low-risk APIs can be tested using lightweight or delayed testing, thus focusing on high-risk APIs. High-risk and low-risk ratings are relative; a standard risk rating can be set. Risk ratings higher than the standard risk rating are considered high-risk, and risk ratings lower than the standard risk rating are considered low-risk.

[0075] In some embodiments of this disclosure, the detection strategy includes: monitoring changes in the API of a first container; and performing black-box API detection on the first container according to the detection strategy, including: for APIs that have not changed, reusing the historical black-box API detection results corresponding to those APIs. By reusing the historical black-box API detection results of APIs that have not changed, invalid detection can be avoided and the detection speed can be improved.

[0076] In some embodiments of this disclosure, the detection strategy includes: if the feature information of the first container is the same as the feature information of any second container, the historical black-box API detection results of the second container are reused. In some embodiments, if the feature information of the first container is the same as the feature information of the second container, it indicates that the first container is the second container or has the same configuration. If the detection results of the historical black-box API of the second container are available, they can be directly reused.

[0077] In some embodiments of this disclosure, black-box API detection is performed on the first container according to a detection strategy, including: caching the detection results of black-box APIs whose access frequency is greater than a preset frequency and whose security status reaches a preset stability standard. In some embodiments, such as... Figure 5 As shown in the caching and result utilization section, the detection results of frequently accessed API interfaces with stable security status can be cached, thereby reducing the time overhead of repeated detection.

[0078] In some embodiments of this disclosure, black-box API detection of the first container is performed according to a detection strategy, including: pre-storing attack methods for vulnerabilities, attacking the first container according to the attack methods for vulnerabilities in the first container, and / or pre-storing attack methods for configuration information risks, attacking the first container according to the attack methods for configuration information risks in the first container. In some embodiments, a database containing attack methods for vulnerabilities and attack methods for configuration information risks can be constructed. This allows for the rapid retrieval of the corresponding attack method from the database when a vulnerability or configuration information risk is detected, and the attack method can then be used for black-box API detection.

[0079] In some embodiments of this disclosure, such as Figure 5As shown in the distributed parallel detection example, black-box API detection can be accelerated using a detection accelerator. Specifically, when performing black-box API detection, a distributed parallel detection approach can be adopted, decomposing the black-box API detection task into multiple units, each responsible for a portion of the API detection work. A dynamic load balancing algorithm can be used to automatically allocate detection tasks based on the real-time load and performance of each detection node, ensuring efficient node operation. Multi-threading or clustering technologies can be used to execute multiple detection tasks simultaneously, reducing overall time consumption.

[0080] In some embodiments of this disclosure, a preset model is optimized based on the detection results of the black-box API detection of the first container. In some embodiments, such as... Figure 5 As shown in the adaptive optimization, for each black-box API detection result, a preset model can be input to optimize the preset model. For example, the black-box API detection result of the first container can be added with historical black-box API detection results to regenerate the preset model.

[0081] In some embodiments of this disclosure, in conjunction with the appendix Figure 2 The method described in this embodiment is explained below. First, a feature acquisition mechanism is introduced. A feature collector gathers metadata of the second container and the second image, constructs feature associations based on this metadata, and builds feature information for the second container based on these associations. Then, leveraging the immutability of the image, a layered static vulnerability detection engine is used to implement image vulnerability detection. Vulnerability and configuration information risk detection is performed on each layer of the second image and the second container to obtain corresponding vulnerability detection results. After obtaining the feature information of the second container and the vulnerability detection results, the association between the feature information and potential risks is obtained by combining a black-box API detection rule base. A preset model is generated based on this association model generator. For the first container, a detection strategy (black-box API detection strategy) is generated based on the preset model, optimizing the detection path. The detection accelerator performs black-box API detection on the first container according to the detection strategy. For multiple copies of the same image, the detection results can be reused, avoiding redundant work. Overall, the black-box API detection of the first container is accelerated. After obtaining the black-box API detection results of the first container, they can be input into the model generator to optimize the preset model. When performing a black-box API test on the first container again in the future, the APIs and configuration information that have not changed will be considered.

[0082] In some embodiments proposed in this disclosure, a dynamic identification method based on container feature information is used. Leveraging container multi-copy and image immutability, metadata such as container basic information, operating system software packages, language packs, middleware software, applications, and configuration information of the image and image layers is dynamically collected and integrated to form comprehensive and real-time updated feature information. A preset model is generated by matching feature information with vulnerabilities. This model, based on container application software, vulnerabilities, and configuration information, filters and prioritizes the APIs of the first container according to the preset model before black-box API scanning. Invalid black-box API detection rule sets are filtered out, generating a specific black-box API detection rule set matching the first container. This ensures highly targeted detection activities, reduces unnecessary traversal, and improves detection efficiency. This disclosure improves security while effectively reducing detection resources and efficiency, and enhancing detection accuracy and efficiency.

[0083] This disclosure also proposes a black-box detection device, comprising:

[0084] The acquisition unit acquires feature information of the first container, which is the container to be detected.

[0085] The control unit is configured to input the feature information of the first container into a preset model to generate a detection strategy for the first container. The preset model is generated based on reference information, which includes: feature information of the second container and historical detection results of the second container corresponding to the feature information of the second container. The number of the second containers is one or more, and the detection strategy for the first container includes: reusable historical detection results of the first container.

[0086] The control unit is further configured to perform black-box API detection on the first container according to the detection strategy.

[0087] In some embodiments, the feature information of the first container is input into a preset model to generate a detection strategy for the first container, including performing one or more of the following operations in the preset model:

[0088] In response to the feature information of the second container and the feature information of the first container indicating that the second container and the first container are instances built from the same image, the reusable historical detection results are determined to include: the historical detection results of the second container;

[0089] In response to the feature information of the second container and the feature information of the first container showing that the first container is built from the first image, the second container is built from the second image, and the first image and the second image have a build dependency relationship, the historical detection results that determine the first container is reusable include: the part of the image layer in the second image that is the same as the first image in the historical detection results;

[0090] After determining the reusable historical detection results of the first container, the vulnerability detection results of the first image are determined; based on the vulnerability detection results of the first image, the detection strategy for the first container is determined.

[0091] In some embodiments, the historical detection results of the second container include: the historical black-box API detection results of the second container, and / or, if the second container is built from a second image, the historical detection results of the second container include: the vulnerability detection results of the second image.

[0092] In some embodiments, the reference information further includes: a black-box API detection rule base; the black-box API detection rule base includes: black-box API detection rules;

[0093] The detection strategy also includes: black-box API detection rules used when performing black-box API detection on the first container.

[0094] In some embodiments, the feature information of the first container or the second container is obtained in the following manner:

[0095] Obtain the metadata of the target container and the metadata of the target image, wherein the target container is a first container or a second container, and the target container is built from the target image;

[0096] A feature association relationship is constructed based on the metadata of the target container and the metadata of the target image;

[0097] The feature information of the target container is generated based on the feature association relationship.

[0098] In some embodiments, one or more of the following conditions are met:

[0099] The feature association relationship is a feature association graph, which takes the target container as a node and one or more of the target image, software package, application and configuration information as association attributes.

[0100] The feature association relationship includes one or more of the following: the instantiation relationship between the target container and the target image, the copy relationship between different containers, the build relationship between different images, the mapping relationship between the application and the port, and the mapping relationship between the target container and the application;

[0101] The characteristic information of the target container includes one or more of the following: the target container's metadata, the target image's metadata, runtime environment, application, and network configuration;

[0102] The feature information of the first container is updated in real time or periodically.

[0103] In some embodiments, the vulnerability detection results of the second image are obtained through at least one of the following methods:

[0104] A layered static vulnerability detection method is adopted to perform vulnerability detection on each layer of the second image, and the vulnerability detection results of the second image are generated based on the detection results of the vulnerability detection.

[0105] A layered static vulnerability detection method is adopted to perform configuration information risk detection on each layer of the second image, and the vulnerability detection results of the second image are generated based on the detection results of the configuration information risk detection.

[0106] In some embodiments, the vulnerability detection results of the second image are obtained by at least one of the following methods:

[0107] Obtain the metadata of the second image and extract software information from the metadata of the second image; load the vulnerability rule base, which includes known vulnerabilities and corresponding software information; perform vulnerability detection based on the software information of the second image and the vulnerability rule base; and generate vulnerability detection results for the second image based on the vulnerability detection results.

[0108] Obtain the metadata of the second image and retrieve configuration information from the metadata of the second image; load the configuration baseline rule base, which includes expected configuration information; perform configuration information risk detection based on the configuration information of the second image and the configuration baseline rule base; and generate the vulnerability detection result of the second image based on the detection result of the configuration information risk detection.

[0109] In some embodiments, at least one of the following is satisfied:

[0110] When performing vulnerability testing on the same second image again, only the parts of the vulnerability rule base that have changed compared to the previous vulnerability testing of the second image are loaded:

[0111] When performing vulnerability detection on the same second image again, only the parts of the configuration baseline rule base that have changed compared to the last vulnerability detection of the second image are loaded.

[0112] In some embodiments, the preset model includes at least one of the following:

[0113] The association between feature information and the black-box API detection rule base is used to determine the black-box API detection rules in the black-box API detection rule base to which the feature information applies.

[0114] The dependencies between black-box API detection rules in the black-box API detection rule base are used to determine the execution order of black-box API detection rules.

[0115] A list of APIs corresponding to the vulnerability detection results, which indicates the priority detection APIs associated with the vulnerability detection results;

[0116] The optimization rules of the black-box API detection rule base are used to adjust the black-box API detection rules in the black-box API detection rule base according to the configuration information.

[0117] API risk rating rules are used to rate the risk of APIs based on historical black-box API detection results.

[0118] Historical black-box API detection result reuse rules are used to reuse the historical black-box API detection results of an API when an API that has not changed is identified.

[0119] The relationship between vulnerabilities and black-box API detection rule bases is used to determine the black-box API detection rules corresponding to vulnerabilities.

[0120] Some embodiments include at least one of the following:

[0121] The detection strategy includes: risk rating of the API of the first container; black-box API detection of the first container according to the detection strategy, including: determining at least one of the detection priority and detection depth of the API of the first container according to the risk rating of the API of the first container.

[0122] The detection strategy includes: changes in the API of the first container; and black-box API detection of the first container according to the detection strategy, including: for APIs that have not changed, reusing the historical black-box API detection results corresponding to the API.

[0123] In some embodiments, black-box API detection of the first container is performed according to the detection strategy, including at least one of the following:

[0124] The detection results of black-box API detection for APIs whose access frequency exceeds the preset frequency and whose security status reaches the preset stability standard are cached.

[0125] The attack methods for pre-stored vulnerabilities are then used to attack the first container based on the attack methods for the vulnerabilities in the first container.

[0126] The system pre-stores attack methods that pose risks based on the configuration information of the first container, and then attacks the first container based on these attack methods.

[0127] In some embodiments, the control unit is also configured to optimize the preset model based on the detection results of the black-box API detection of the first container.

[0128] For embodiments of the apparatus, since they basically correspond to the method embodiments, relevant details can be found in the descriptions of the method embodiments. The apparatus embodiments described above are merely illustrative, and the modules described as separate modules may or may not be separate. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0129] The methods and apparatus of this disclosure have been described above based on embodiments and application examples. Furthermore, this disclosure also provides an electronic device and a computer-readable storage medium, which are described below.

[0130] The following is for reference. Figure 6 The figure illustrates a structural schematic of an electronic device (e.g., a terminal device or server) 800 suitable for implementing embodiments of the present disclosure. The terminal device in the embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. The electronic device shown in the figure is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present disclosure.

[0131] Electronic device 800 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 801, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 802 or a program loaded from storage device 808 into random access memory (RAM) 803. RAM 803 also stores various programs and data required for the operation of electronic device 800. The processing device 801, ROM 802, and RAM 803 are interconnected via bus 804. Input / output (I / O) interface 805 is also connected to bus 804.

[0132] Typically, the following devices can be connected to I / O interface 805: input devices 806 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 807 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 808 including, for example, magnetic tapes, hard disks, etc.; and communication devices 809. Communication device 809 allows electronic device 800 to communicate wirelessly or wiredly with other devices to exchange data. Although an electronic device 800 with various devices is shown in the figure, it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0133] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 809, or installed from a storage device 808, or installed from a ROM 802. When the computer program is executed by a processing device 801, it performs the functions defined in the methods of embodiments of this disclosure.

[0134] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0135] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0136] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0137] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the methods of the present disclosure.

[0138] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0139] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0140] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0141] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0142] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0143] According to one or more embodiments of this disclosure, a method for detecting a container's black-box API is provided, comprising:

[0144] Obtain feature information of the first container, which is the container to be detected;

[0145] The feature information of the first container is input into a preset model to generate a detection strategy for the first container. The preset model is generated based on reference information, which includes: feature information of the second container and historical detection results of the second container corresponding to the feature information of the second container. The number of the second containers is one or more, and the detection strategy of the first container includes: reusable historical detection results of the first container.

[0146] The first container is subjected to black-box API detection according to the detection strategy.

[0147] According to one or more embodiments of this disclosure, a black-box API detection method for a container is provided, wherein feature information of the first container is input into a preset model to generate a detection strategy for the first container, including performing one or more of the following operations in the preset model:

[0148] In response to the feature information of the second container and the feature information of the first container indicating that the second container and the first container are instances built from the same image, the reusable historical detection results are determined to include: the historical detection results of the second container;

[0149] In response to the feature information of the second container and the feature information of the first container showing that the first container is built from the first image, the second container is built from the second image, and the first image and the second image have a build dependency relationship, the historical detection results that determine the first container is reusable include: the part of the image layer in the second image that is the same as the first image in the historical detection results;

[0150] After determining the reusable historical detection results of the first container, the vulnerability detection results of the first image are determined; based on the vulnerability detection results of the first image, the detection strategy for the first container is determined.

[0151] According to one or more embodiments of this disclosure, a method for black-box API detection of a container is provided, wherein the historical detection results of the second container include: the historical black-box API detection results of the second container, and / or,

[0152] The second container is built from the second image, and the historical detection results of the second container include the vulnerability detection results of the second image.

[0153] According to one or more embodiments of this disclosure, a method for black-box API detection of a container is provided, wherein the reference information further includes: a black-box API detection rule base; the black-box API detection rule base includes: black-box API detection rules;

[0154] The detection strategy also includes: black-box API detection rules used when performing black-box API detection on the first container.

[0155] According to one or more embodiments of this disclosure, a black-box API detection method for a container is provided, wherein the feature information of the first container or the second container is obtained in the following manner:

[0156] Obtain the metadata of the target container and the metadata of the target image, wherein the target container is a first container or a second container, and the target container is built from the target image;

[0157] A feature association relationship is constructed based on the metadata of the target container and the metadata of the target image;

[0158] The feature information of the target container is generated based on the feature association relationship.

[0159] According to one or more embodiments of this disclosure, a method for black-box API detection of a container is provided, characterized in that it satisfies one or more of the following:

[0160] The feature association relationship is a feature association graph, which takes the target container as a node and one or more of the target image, software package, application and configuration information as association attributes.

[0161] The feature association relationship includes one or more of the following: the instantiation relationship between the target container and the target image, the copy relationship between different containers, the build relationship between different images, the mapping relationship between the application and the port, and the mapping relationship between the target container and the application;

[0162] The characteristic information of the target container includes one or more of the following: the target container's metadata, the target image's metadata, runtime environment, application, and network configuration;

[0163] The feature information of the first container is updated in real time or periodically.

[0164] According to one or more embodiments of this disclosure, a method for black-box API detection of a container is provided, wherein the vulnerability detection result of the second image is obtained through at least one of the following methods:

[0165] A layered static vulnerability detection method is adopted to perform vulnerability detection on each layer of the second image, and the vulnerability detection results of the second image are generated based on the detection results of the vulnerability detection.

[0166] A layered static vulnerability detection method is adopted to perform configuration information risk detection on each layer of the second image, and the vulnerability detection results of the second image are generated based on the detection results of the configuration information risk detection.

[0167] According to one or more embodiments of this disclosure, a black-box API detection method for a container is provided, which obtains the vulnerability detection result of the second image by at least one of the following methods:

[0168] Obtain the metadata of the second image and extract software information from the metadata of the second image; load the vulnerability rule base, which includes known vulnerabilities and corresponding software information; perform vulnerability detection based on the software information of the second image and the vulnerability rule base; and generate vulnerability detection results for the second image based on the vulnerability detection results.

[0169] Obtain the metadata of the second image and retrieve configuration information from the metadata of the second image; load the configuration baseline rule base, which includes expected configuration information; perform configuration information risk detection based on the configuration information of the second image and the configuration baseline rule base; and generate the vulnerability detection result of the second image based on the detection result of the configuration information risk detection.

[0170] According to one or more embodiments of this disclosure, a method for detecting a container's black-box API is provided, the method comprising at least one of the following:

[0171] When performing vulnerability testing on the same second image again, only the parts of the vulnerability rule base that have changed compared to the previous vulnerability testing of the second image are loaded:

[0172] When performing vulnerability detection on the same second image again, only the parts of the configuration baseline rule base that have changed compared to the last vulnerability detection of the second image are loaded.

[0173] According to one or more embodiments of this disclosure, a method for detecting a container's black-box API is provided, wherein the preset model includes at least one of the following:

[0174] The association between feature information and the black-box API detection rule base is used to determine the black-box API detection rules in the black-box API detection rule base to which the feature information applies.

[0175] The dependencies between black-box API detection rules in the black-box API detection rule base are used to determine the execution order of black-box API detection rules.

[0176] A list of APIs corresponding to the vulnerability detection results, which indicates the priority detection APIs associated with the vulnerability detection results;

[0177] The optimization rules of the black-box API detection rule base are used to adjust the black-box API detection rules in the black-box API detection rule base according to the configuration information.

[0178] API risk rating rules are used to rate the risk of APIs based on historical black-box API detection results.

[0179] Historical black-box API detection result reuse rules are used to reuse the historical black-box API detection results of an API when an API that has not changed is identified.

[0180] The relationship between vulnerabilities and black-box API detection rule bases is used to determine the black-box API detection rules corresponding to vulnerabilities.

[0181] According to one or more embodiments of this disclosure, a method for detecting a container's black-box API is provided, the method comprising at least one of the following:

[0182] The detection strategy includes: risk rating of the API of the first container; black-box API detection of the first container according to the detection strategy, including: determining at least one of the detection priority and detection depth of the API of the first container according to the risk rating of the API of the first container.

[0183] The detection strategy includes: changes in the API of the first container; and black-box API detection of the first container according to the detection strategy, including: for APIs that have not changed, reusing the historical black-box API detection results corresponding to the API.

[0184] According to one or more embodiments of this disclosure, a method for black-box API detection of a container is provided, wherein black-box API detection of the first container is performed according to the detection strategy, including at least one of the following:

[0185] The detection results of black-box API detection for APIs whose access frequency exceeds the preset frequency and whose security status reaches the preset stability standard are cached.

[0186] The attack methods for pre-stored vulnerabilities are then used to attack the first container based on the attack methods for the vulnerabilities in the first container.

[0187] The system pre-stores attack methods that pose risks based on the configuration information of the first container, and then attacks the first container based on these attack methods.

[0188] According to one or more embodiments of this disclosure, a method for detecting a container's black-box API is provided, further comprising:

[0189] The preset model is optimized based on the detection results of the black-box API detection of the first container.

[0190] According to one or more embodiments of this disclosure, a black-box API testing device for a container is provided, comprising:

[0191] The acquisition unit acquires feature information of the first container, which is the container to be detected.

[0192] The control unit is configured to input the feature information of the first container into a preset model to generate a detection strategy for the first container. The preset model is generated based on reference information, which includes: feature information of the second container and historical detection results of the second container corresponding to the feature information of the second container. The number of the second containers is one or more, and the detection strategy for the first container includes: reusable historical detection results of the first container.

[0193] The control unit is further configured to perform black-box API detection on the first container according to the detection strategy.

[0194] According to one or more embodiments of the present disclosure, an electronic device is provided, including: at least one memory and at least one processor;

[0195] The at least one memory is used to store program code, and the at least one processor is used to call the program code stored in the at least one memory to execute the method described in any one of the above.

[0196] According to one or more embodiments of the present disclosure, a computer-readable storage medium is provided for storing program code that, when executed by a processor, causes the processor to perform the methods described above.

[0197] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0198] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0199] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A method for black-box API detection of a container, characterized in that, include: Obtain feature information of the first container, which is the container to be detected; The feature information of the first container is input into a preset model to generate a detection strategy for the first container. The preset model is generated based on reference information, which includes: feature information of the second container, historical detection results of the second container corresponding to the feature information of the second container, and a black-box API detection rule base. The black-box API detection rule base includes black-box API detection rules. The preset model includes the association between vulnerabilities and the black-box API detection rule base, which is used to determine the black-box API detection rules corresponding to the vulnerabilities. The number of second containers can be one or more. The detection strategy for the first container includes: reusable historical detection results of the first container, and the black-box API detection rules used when performing black-box API detection on the first container. The first container is subjected to black-box API detection according to the detection strategy. The feature information of the first container is input into a preset model to generate a detection strategy for the first container, including performing the following operations in the preset model: After determining the reusable historical test results of the first container, the vulnerability test results of the first image are determined; the vulnerability test results of the first image include potential vulnerabilities. Based on the vulnerability detection results of the first image, a detection strategy for the first container is determined. The preset model also includes a list of APIs corresponding to the vulnerability detection results, which represents the priority detection APIs associated with the vulnerability detection results. The detection strategy is used to indicate the priority detection APIs.

2. The method according to claim 1, characterized in that, The feature information of the first container is input into a preset model to generate a detection strategy for the first container, and the following operations are performed in the preset model: In response to the feature information of the second container and the feature information of the first container indicating that the second container and the first container are instances built from the same image, the historical detection results that determine the first container is reusable include: the historical detection results of the second container; In response to the feature information of the second container and the feature information of the first container showing that the first container is built from the first image, the second container is built from the second image, and the first image and the second image have a build dependency relationship, the historical detection results that determine the first container is reusable include: the part of the image layer in the second image that is the same as the first image in the historical detection results.

3. The method according to claim 1, characterized in that, The historical detection results of the second container include: the historical black-box API detection results of the second container, and / or, The second container is built from the second image, and the historical detection results of the second container include the vulnerability detection results of the second image.

4. The method according to claim 1, characterized in that, The feature information of the first container or the second container is obtained in the following manner: Obtain the metadata of the target container and the metadata of the target image, wherein the target container is a first container or a second container, and the target container is built from the target image; A feature association relationship is constructed based on the metadata of the target container and the metadata of the target image; The feature information of the target container is generated based on the feature association relationship.

5. The method according to claim 4, characterized in that, It meets one or more of the following conditions: The feature association relationship is a feature association graph, in which the target container is the node and one or more of the target image, software package, application and configuration information are the association attributes. The feature association relationship includes one or more of the following: the instantiation relationship between the target container and the target image, the copy relationship between different containers, the build relationship between different images, the mapping relationship between the application and the port, and the mapping relationship between the target container and the application; The characteristic information of the target container includes one or more of the following: the target container's metadata, the target image's metadata, runtime environment, application, and network configuration; The feature information of the first container is updated in real time or periodically.

6. The method according to claim 3, characterized in that, The vulnerability detection results of the second image are obtained through at least one of the following methods: A layered static vulnerability detection method is adopted to perform vulnerability detection on each layer of the second image, and the vulnerability detection results of the second image are generated based on the detection results of the vulnerability detection. A layered static vulnerability detection method is adopted to perform configuration information risk detection on each layer of the second image, and the vulnerability detection results of the second image are generated based on the detection results of the configuration information risk detection.

7. The method according to claim 3, characterized in that, The vulnerability detection results of the second image are obtained by at least one of the following methods: Obtain the metadata of the second image, and extract software information from the metadata of the second image; Load a vulnerability rule base, which includes: known vulnerabilities and corresponding software information; perform vulnerability detection based on the software information of the second image and the vulnerability rule base; and generate vulnerability detection results for the second image based on the vulnerability detection results. Obtain the metadata of the second image and retrieve configuration information from the metadata of the second image; load the configuration baseline rule base, which includes expected configuration information; perform configuration information risk detection based on the configuration information of the second image and the configuration baseline rule base; and generate the vulnerability detection result of the second image based on the detection result of the configuration information risk detection.

8. The method according to claim 7, characterized in that, The method includes at least one of the following: When performing vulnerability testing on the same second image again, only the parts of the vulnerability rule base that have changed compared to the previous vulnerability testing of the second image are loaded: When performing vulnerability detection on the same second image again, only the parts of the configuration baseline rule base that have changed compared to the last vulnerability detection of the second image are loaded.

9. The method according to claim 1, characterized in that, The preset model also includes at least one of the following: The association between feature information and the black-box API detection rule base is used to determine the black-box API detection rules in the black-box API detection rule base to which the feature information applies. The dependencies between black-box API detection rules in the black-box API detection rule base are used to determine the execution order of black-box API detection rules. The optimization rules of the black-box API detection rule base are used to adjust the black-box API detection rules in the black-box API detection rule base according to the configuration information. API risk rating rules are used to rate the risk of APIs based on historical black-box API detection results. Historical black-box API detection result reuse rules are used to reuse the historical black-box API detection results of an API when an API that has not changed is identified.

10. The method according to claim 1, characterized in that, The method includes at least one of the following: The detection strategy includes: risk rating of the API of the first container; black-box API detection of the first container according to the detection strategy, including: determining at least one of the detection priority and detection depth of the API of the first container according to the risk rating of the API of the first container. The detection strategy includes: changes in the API of the first container; and black-box API detection of the first container according to the detection strategy, including: for APIs that have not changed, reusing the historical black-box API detection results corresponding to the API.

11. The method according to claim 1, characterized in that, The first container is subjected to black-box API detection according to the detection strategy, including at least one of the following: The detection results of black-box API detection for APIs whose access frequency exceeds the preset frequency and whose security status reaches the preset stability standard are cached. The attack methods for pre-stored vulnerabilities are then used to attack the first container based on the attack methods for the vulnerabilities in the first container. The system pre-stores attack methods that pose risks based on the configuration information of the first container, and then attacks the first container based on these attack methods.

12. The method according to claim 1, characterized in that, Also includes: The preset model is optimized based on the detection results of the black-box API detection of the first container.

13. A black-box API testing device for containers, characterized in that, include: The acquisition unit acquires feature information of the first container, which is the container to be detected. A control unit is configured to input the feature information of the first container into a preset model to generate a detection strategy for the first container. The preset model is generated based on reference information, which includes: feature information of the second container, historical detection results of the second container corresponding to the feature information of the second container, and a black-box API detection rule base. The black-box API detection rule base includes black-box API detection rules. The preset model includes the association between vulnerabilities and the black-box API detection rule base, which is used to determine the black-box API detection rules corresponding to the vulnerabilities. The number of second containers is one or more. The detection strategy for the first container includes: reusable historical detection results of the first container, and the black-box API detection rules used when performing black-box API detection on the first container. The control unit is further configured to perform black-box API detection on the first container according to the detection strategy; The feature information of the first container is input into a preset model to generate a detection strategy for the first container, including performing the following operations in the preset model: After determining the reusable historical test results of the first container, the vulnerability test results of the first image are determined, including potential vulnerabilities. Based on the vulnerability detection results of the first image, a detection strategy for the first container is determined. The preset model also includes a list of APIs corresponding to the vulnerability detection results, which represents the priority detection APIs associated with the vulnerability detection results. The detection strategy is used to indicate the priority detection APIs.

14. An electronic device, comprising: At least one memory and at least one processor; The at least one memory is used to store program code, and the at least one processor is used to call the program code stored in the at least one memory to execute the method of any one of claims 1 to 12.

15. A computer-readable storage medium for storing program code that, when executed by a processor, causes the processor to perform the method of any one of claims 1 to 12.

Images