System and method for improving inspection of software containers

Abstract

A system and method for improving inspection of software containers is presented. The method comprises the following steps: detecting a plurality of configuration files, wherein each configuration file corresponds to a software container mirror image corresponding to a software container deployed in a cloud computing environment; parsing the first profile to detect a first plurality of commands; generating a first fingerprint based on the detected first plurality of commands; parsing the second profile to detect a second plurality of commands; generating a second fingerprint based on the detected second plurality of commands; determining that the first configuration file is matched with the second configuration file in response to matching detected based on the fingerprint; in response to the detected mismatch, determining that the first configuration file is not matched with the second configuration file; and in response to determining that the first configuration file is matched with the second configuration file, checking the network security object in the first configuration file.

Description

Technical Field

[0001] This disclosure generally relates to the field of detecting cybersecurity threats, particularly using the fingerprinting of software container configuration files to detect cybersecurity threats. Background Technology

[0002] Operating system-level virtualization describes various efforts that attempt to efficiently provide hardware resources (virtualization) while containing these resources within themselves, preventing other tenants on the same system from accessing each other's systems, files, etc., unless such access is specifically granted.

[0003] Containers are deployed in cloud computing environments, such as Virtual Private Clouds (VPCs) of cloud infrastructure, such as Amazon® Web Services (AWS), Google® Cloud Platform (GCP), and Microsoft® Azure. Containers are deployed from mount points of container images by container engines (such as RKT, Docker®, etc.). Containers (such as Docker® containers) can be built from multiple container images (also called layers). Layers are created whenever changes are made to a container image, such as mounting applications, adding files, deleting files, or updating registry values.

[0004] Container files (such as Dockerfiles®) are used to create containers that may be exposed to cybersecurity threats, secrets, vulnerabilities, and other threats. Therefore, inspecting container files to detect such cybersecurity threats and vulnerabilities is crucial. However, inspecting containers and their files for cybersecurity threats and vulnerabilities consumes significant resources, including processing memory and storage devices.

[0005] Therefore, it would be beneficial to provide a solution that overcomes the above challenges. Summary of the Invention

[0006] The following is an overview of several example embodiments of this disclosure. This overview is provided to facilitate a basic understanding of these embodiments and is not intended to limit the breadth of this disclosure. This overview is not a comprehensive summary of all contemplated embodiments, nor is it intended to identify key or essential elements of all embodiments, nor to describe the scope of any or all aspects. Its sole purpose is to present some concepts of one or more embodiments in a simplified form as a prelude to the more detailed description that follows. For convenience, the terms "some embodiments" or "certain embodiments" may be used herein to refer to a single or multiple embodiments of this disclosure.

[0007] A system of one or more computers can be configured to perform specific operations or actions by mounting software, firmware, hardware, or a combination thereof on the system, which in operation cause the system to perform actions. A system of one or more computer programs can be configured to perform specific operations or actions by including instructions that, when executed by a data processing device, cause the device to perform those actions.

[0008] In one general aspect, a method may include detecting a plurality of profiles, each profile corresponding at least to a software container image corresponding to a software container deployed in a cloud computing environment. The method may further include parsing a first profile among the plurality of profiles to detect a first plurality of commands. The method may further include generating a first fingerprint based at least on the detected first plurality of commands. The method may further include parsing a second profile among the plurality of profiles to detect a second plurality of commands. The method may further include generating a second fingerprint based at least on the detected second plurality of commands. The method may further include determining that a first profile matches a second profile in response to detecting a match based on the first and second fingerprints. The method may further include determining that a first profile does not match a second profile in response to detecting a mismatch based on the first and second fingerprints. The method may further include checking for network security objects in the first profile in response to determining that the first profile matches the second profile. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method.

[0009] Implementations may include one or more of the following features. The method may include: generating a second fingerprint if it is determined that a first profile does not match a second profile. The method may include: generating another second fingerprint based on a profile that is not the second profile. The method may include: generating a first fingerprint based on commands, command counts, command sequences, command configurations, command arguments, command parameters, and any combination thereof. The method may include: generating a second fingerprint based on commands, command counts, command sequences, command configurations, and any combination thereof. The method may include: parsing a first profile to detect code objects, code, commands, and any combination thereof. The method may include: parsing a second profile to detect code objects, code, commands, and any combination thereof. The method may include: detecting cybersecurity objects, wherein the cybersecurity objects are associated with cybersecurity threats. Cybersecurity threats in this method include any of the following: exposures, vulnerabilities, malware, ransomware, spyware, misconfigurations, and any combination thereof. Implementations of the described techniques may include hardware, methods or processes, or tangible computer media.

[0010] In one general aspect, a non-transitory computer-readable medium may include one or more instructions that, when executed by one or more processors of a device, cause the device to: detect a plurality of profiles, each profile corresponding at least to a software container image corresponding to a software container deployed in a cloud computing environment; parse a first profile among the plurality of profiles to detect a first plurality of commands; generate a first fingerprint based at least on the detected first plurality of commands; parse a second profile among the plurality of profiles to detect a second plurality of commands; generate a second fingerprint based at least on the detected second plurality of commands; determine that the first profile matches the second profile in response to a match detected based on the first and second fingerprints; determine that the first profile does not match the second profile in response to a mismatch detected based on the first and second fingerprints; and examine a network security object in the first profile in response to the determination that the first profile matches the second profile. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method.

[0011] In one general aspect, the system may include one or more processors configured to: detect a plurality of profiles, each profile corresponding at least to a software container image corresponding to a software container deployed in a cloud computing environment. The system may also parse a first profile from the plurality of profiles to detect a first plurality of commands. The system may also generate a first fingerprint based at least on the detected first plurality of commands. The system may also parse a second profile from the plurality of profiles to detect a second plurality of commands. The system may also generate a second fingerprint based at least on the detected second plurality of commands. The system may also determine that the first profile matches the second profile in response to a match detected based on the first and second fingerprints. The system may also determine that the first profile does not match the second profile in response to a mismatch detected based on the first and second fingerprints. The system may also examine a network security object in the first profile in response to determining that the first profile matches the second profile. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method.

[0012] The implementation may include one or more of the following features. In this system, one or more processors are further configured to generate a second fingerprint if it is determined that the first profile does not match the second profile. In this system, one or more processors are further configured to generate another second fingerprint based on a different profile that is not the second profile. In this system, one or more processors are further configured to generate a first fingerprint based on commands, command counts, command sequences, command configurations, command arguments, command parameters, and any combination thereof. In this system, one or more processors are further configured to generate a second fingerprint based on commands, command counts, command sequences, command configurations, and any combination thereof. In this system, one or more processors are further configured to parse the first profile to detect code objects, code, commands, and any combination thereof. In this system, one or more processors are further configured to parse the second profile to detect code objects, code, commands, and any combination thereof. In this system, one or more processors are further configured to detect cybersecurity objects, wherein the cybersecurity objects are associated with cybersecurity threats. In this system, cybersecurity threats include any of the following: exposures, vulnerabilities, malware, ransomware, spyware, misconfigurations, and any combination thereof. Implementations of the described technology may include hardware, methods or processes, or tangible computer media. Attached Figure Description

[0013] The subject matter disclosed herein is specifically pointed out and expressly claimed in the claims of the specification. The above and other objects, features, and advantages of the disclosed embodiments will become apparent from the following detailed description taken in conjunction with the accompanying drawings.

[0014] Figure 1 This is a schematic diagram illustrating container deployment for describing some embodiments of the present disclosure.

[0015] Figure 2 This is a network diagram used to describe the embodiments, including a production environment and an inspection environment.

[0016] Figure 3 This is a schematic diagram used to describe the difference generation process of the embodiment.

[0017] Figure 4 This is a flowchart illustrating the implementation of an embodiment for reducing redundancy in inspecting network security threats at the container layer.

[0018] Figure 5 This is a flowchart of a method for reducing redundancy in network security threats to inspecting active containers, implemented according to an embodiment.

[0019] Figure 6 This is a flowchart of a layer-by-layer inspection method for operating system-level virtualization implemented according to an embodiment.

[0020] Figure 7 This is a flowchart of a method for detecting network security objects in an operating system-level virtualization software product, implemented according to an embodiment.

[0021] Figure 8 This is a flowchart of a method for improving software container inspection using fingerprints, implemented according to an embodiment.

[0022] Figure 9 This is a schematic diagram of an inspection controller according to an embodiment. Detailed Implementation

[0023] It is important to note that the embodiments disclosed herein are merely examples of the many advantageous uses of the inventive teachings herein. In general, the statements in this specification do not necessarily limit any of the various claimed embodiments. Furthermore, some statements may apply to some inventive features but not to others. Generally, unless otherwise stated, singular elements may be plural, and vice versa, without loss of generality. In the drawings, the same numerals denote the same parts in several views.

[0024] The various example embodiments disclosed herein include systems and methods for deploying code objects to a cloud computing environment using unique fingerprint tracking. In embodiments, a container is a software package that includes an application and the dependencies required to run that application. In some embodiments, dependencies are, for example, libraries, binaries, etc. Therefore, in embodiments, a container virtualized within an operating system allows the container to run anywhere.

[0025] In various embodiments, the system of this disclosure is configured to inspect and analyze container profiles to detect cybersecurity threats. In embodiments, this disclosure is configured to detect container profile matches based on command type, command sequence, formal parameter quantity, and combinations thereof. In various embodiments, this allows for a reduction in the number of objects that would otherwise need to be inspected by performing a comprehensive inspection of active containers (i.e., inspecting every object within an active container).

[0026] In various embodiments, this inspection not only reduces the use of processing and storage resources for inspection, but also reduces the bandwidth of the active container used by the inspector, thereby minimizing the impact of inspecting the active container.

[0027] Figure 1This is an example diagram of container deployment 100 used according to an embodiment. Container engine 110 is a software application deployed in a cloud computing environment (or infrastructure). In this embodiment, container engine 110 is configured to receive user input, process input and other communications with a container orchestrator, retrieve container images from a repository server, generate mount points from the container images, generate metadata based on the container images, etc. In some embodiments, container engine 110 is also configured to invoke a container runtime to actually deploy the container from the container image. For example, the container engine could be Docker®. For example, the container runtime could be... runc .

[0028] In some embodiments, container engine 110 may be deployed within container virtual machines 102, which are virtual machines running container engine 110. In some embodiments, the container virtual machines are communicatively coupled to container orchestrator 105. Container orchestrator 105 may be communicatively coupled to multiple container virtual machines 102, each running one container engine 110. For example, container orchestrator 105 may be a Kubernetes® container orchestration system, and container engine 110 may be a Docker® engine.

[0029] Container engine 110 is configured to extract container images stored in repository 120. In an embodiment, repository 120 is implemented as a storage device and exposed by a server (not shown) that communicates with container engine 110, for example, via a network interface, in order to extract container images from it, for example, based on an image identifier.

[0030] Repository 120 can host multiple container images, such as container images 140-1 to 140-N, individually referred to as container image 140, and commonly referred to as container image 140, where "N" is an integer with a value of "2" or greater.

[0031] Each container image 140 can further include additional container images, also known as layers. When a build command is executed on the first container image, a container image (layer) is generated. For example, the first container image (i.e., the parent image) 141 is generated by the first build command. The second build command results in the generation of a second image (i.e., a child image) 140-1 based on the first container image 141.

[0032] In container deployment, a base image is a container image from which other container images can be generated, and it has no parent image. In this embodiment, the base image includes an operating system and software tools that allow mounting software packages or otherwise updating container images. In the example above, the first container image 141 is the base image. The second image 140-1 may include multiple layers, which are not shown herein for simplicity.

[0033] In this embodiment, any of the container images 140 can be an intermediate image, sometimes incorrectly referred to as a base image. An intermediate image is an image that includes the base image and also includes at least one additional layer to add functionality to the deployed container. To reduce the number of layers, a multi-stage build process can be employed. For example, in Docker®, multiple FROM statements can be used to invoke different base images, each FROM statement initiating a new stage in the build. Objects can be selected from one stage to the next, allowing unselected objects to be discarded from the final image.

[0034] In cases where container image 140 may include multiple images, such as container image 140-1 which includes container image 141, container engine 110 typically specifies the mount point for deploying the active container. Container engine 110 may deploy or otherwise configure another workload to deploy the active container. For example, container engine 110 may configure host virtual machine (VM) 130 to deploy multiple containers 150-1 through 150-M on it, individually referred to as container 150, and commonly referred to as multiple containers 150, where "M" is an integer with a value of "2" or greater.

[0035] In one embodiment, VM 130 may run a host, such as a Red Hat® Enterprise Linux (RHEL) Atomic Host, which runs containerized processes (i.e., containers) that are supplied with resources from VM 130. In other embodiments, the host application (e.g., RHEL Atomic Host) may run as a virtual instance in a cloud computing environment, as a local machine (i.e., bare metal) in a network environment, and so on.

[0036] In this embodiment, container engine 110 is also configured to generate a diff. A diff is a term referring to a difference, in this case, the difference between the first container image 141 and the second container image 140-1. Differences can also be generated between container image 140-N and the active container 150-1 deployed based on container image 140-N. References will follow below. Figure 3 The generation of differences will be discussed in more detail.

[0037] Figure 2This is an example network diagram 200 used to describe an embodiment, including a production environment 202 and an inspection environment 205. The production environment 202 is a cloud computing environment that provides services and resources to client devices. Client devices (not shown) can be, for example, laptops, personal computers, other computing devices in an external network of the cloud computing environment, etc. The production environment 202 can be implemented as, for example, a VPC on a cloud computing infrastructure (e.g., Amazon® Web Services (AWS), Google® Cloud Platform (GCP), Microsoft® Azure, etc.).

[0038] In this embodiment, production environment 202 includes cloud entities such as resources and entities. Resources are cloud entities that provide functions such as processing power, memory, storage devices, and communication. Resources can provide a variety of functions. Resources may include, for example, virtual machines (VMs, such as VM 230), container engines (such as container engine 210), serverless functions (not shown), etc.

[0039] In this embodiment, the production environment 202 may also include an application programming interface (API) through which actions in the cloud environment can be triggered. The container engine 210 may be implemented using Kubernetes® or Docker®. In this embodiment, serverless functions are implemented using Lambda®. In some embodiments, the VM 230 is implemented using Oracle® VirtualBox, Azure Virtual Machines, etc. In some embodiments, the container engine 210 may be configured to run the VM 230 to run containerized application 250 (also referred to as container 250). The container engine 210 is configured to access a repository 220 (e.g., the AWS Elastic Container Registry (ECS)), pull images from that repository, and mount them at mount points to create active containers (e.g., container 250).

[0040] An entity is a cloud entity that acts on a resource, meaning it can request or otherwise initiate actions or operations within the cloud environment, thereby enabling the resource to perform functions. An entity can be, for example, a user account, service account, role, etc. In embodiments, an entity is implemented as a data structure that includes information about the entity, such as username, password hash, associated roles, etc. In embodiments, an entity may include privileges that allow the entity to configure container engine 210 to run containers.

[0041] Production environment 202 is connected to inspection environment 205. Inspection environment 205 is a cloud computing environment. In embodiments, inspection environment 205 is deployed on a cloud computing infrastructure shared with production environment 202, or on a separate cloud computing infrastructure not shared with production environment 204, or a combination of both. In some embodiments, a portion of inspection environment 205 is deployed in cloud production environment 202. In some embodiments, certain workloads deployed in inspection environment 205 may also be deployed in production environment 205. For example, inspection environment 205 may have access to principals (e.g., service accounts), which allows inspection environment 205 to initiate actions in production environment 202.

[0042] The inspection environment 205 includes multiple inspector workloads (e.g., inspector 270). In an embodiment, inspector 270 is configured to inspect for cybersecurity threats in virtual instances (e.g., container images) of the production environment 202. Inspector 270 can inspect secure objects (e.g., secrets, keys, user account information, etc.) in containers, container images, etc. In some embodiments, inspector 270 is configured to inspect applications, operating systems, binaries, library files, combinations thereof, etc., in virtual instances.

[0043] The inspection environment 205 also includes a security database 240, which serves as a graph database. The security graph may be stored on the security database 240. The security graph includes a representation of the production environment 202. For example, cloud entities in the production environment 202 may each be represented as nodes in the security graph. In embodiments, the security graph is generated based on objects detected by an inspector (e.g., inspector 270). In some embodiments, virtual instances (e.g., virtual machines) are represented by nodes stored in the security graph.

[0044] Containers (e.g., container 250) and their corresponding images are also represented by nodes, where the node representing container 250 is connected to the node representing the virtual instance (i.e., VM 230) running container 250. In some embodiments, generating instructions to inspect the virtual instance (i.e., container 250) also includes querying a security graph to determine the identifier of the container image represented by the node connected to the node representing container 250.

[0045] The inspection environment 205 also includes an inspection controller 260 (also referred to as controller 260). In an embodiment, controller 260 is a workload deployed in the inspection environment 205 that is configured to initiate inspections of cloud entities (such as the cloud entities discussed above) in the production environment 202. For example, initiating an inspection may include determining which cloud entities to inspect, when to inspect them, etc.

[0046] Inspecting virtual instances (such as container 250) is a process that utilizes resources in the production environment 202, such as processing power (measured in I / O per second (IOPS), storage devices (e.g., for generating snapshots for storage and inspection), etc. Furthermore, when inspecting active containers, instances can dedicate less of their own resources to serving their purpose (e.g., providing services) because these resources are partially used for the inspection process (e.g., sending and receiving communications from inspector 270). Therefore, minimizing this usage is advantageous while still being able to inspect for cybersecurity threats across the entire contents of the container.

[0047] In one embodiment, controller 260 may be configured to instruct container engine 210 to generate a difference between a first container image and a second container image. In another embodiment, controller 260 may be configured to instruct container engine 210 to generate a difference between the active container (i.e., container 250) and the image on which the active container is deployed. Controller 260 may also be configured to instruct inspector 270 to inspect, for example, objects that are part of the difference result, as well as the image on which the active container is deployed. The following will combine... Figure 3 This will be discussed in more detail.

[0048] Figure 3 This is an example schematic diagram illustrating the difference generation process 300 for an embodiment. A container engine 320 (e.g., the Docker® engine) is configured to receive instructions to generate differences between a first container image and a second container image. In this embodiment, the container image (in addition to the base image) comprises multiple container layers. Each container layer is itself a container image. Each container layer corresponds to a single instruction stored in a build file (e.g., a Dockerfile® for the Docker® engine). The build file can be generated according to standards managed by the Open Container Initiative (OCI), which allows for easy transfer of build files, container images, etc., between systems.

[0049] Build files can include multiple build instructions (such as RUN, ADD, and COPY). When the container engine executes each of these instructions, it generates a container layer, also known as an intermediate layer. Intermediate layers are read-only because any modifications will generate a new layer. The top layer of the container image, also called the container layer, upper layer, runtime layer, etc., is a writable layer.

[0050] In this embodiment, the container engine 320 can receive input in the form of instructions from a command line. For example: container-diff diff --type=apt --type=file image1 imageK When executed in the command line, this will generate a diff 332. The diff 332 generated from the above command includes objects and object identifiers, such as what operating system (OS) packages were installed between image1 310-1 and imageK 310-K, and what files were added, deleted, or modified. For example, an object can be a file, and the corresponding object identifier can include the directory path (or address) where the object is stored, as well as the filename or other identifiers used to identify files within that directory.

[0051] container-diff The command is a GitHub® project created by Google®. It should be noted that the example diff generation command given in this document is for educational purposes only, and another similar command or set of commands, or equivalent commands or sets of commands, may be used within the scope of this disclosure. As another example, the container engine is configured to generate a diff 334 between runtime layer 312 and image layer 310-K, from which runtime layer 312 is generated.

[0052] In this embodiment, the difference outputs 332 and 334 are read by the inspector controller 340. The inspector controller 340 may be implemented as described above. Figure 2 The inspector controller 260 is configured to receive difference files and to generate instructions, which, when executed, configure the inspector (e.g., ...). Figure 2 The inspector 270 examines the container image and the objects selected from the difference output, where the difference output is based on the container image.

[0053] For example, inspector controller 340 is also configured to receive a difference output 334 generated between runtime layer 312 and imageK 310-K. In this example, difference output 334 includes objects corresponding to files added in runtime layer 312 that do not appear in imageK 310-K. Inspector controller 340 is then configured to generate instructions that, when executed, the inspector is configured to inspect imageK 310-K and examine objects from difference output 334. By accessing only objects from difference output 334, rather than inspecting the entire runtime layer 312, resource usage is reduced and redundant checks are eliminated, as described above.

[0054] As another example, inspector controller 340 is configured to receive a difference output 332 generated between imageK 310-K and image1 310-1, based on which imageK 310-K is based. In this example, difference output 332 includes objects corresponding to the installation package added to imageK 310-K, and these objects do not appear in image1 310-1. Inspector controller 340 is configured to generate instructions, when executed, that the inspector is configured to inspect image1 310-1 and examine objects from difference output 332. By accessing only objects from difference output 332, rather than inspecting the entire imageK 310-K, resource usage is reduced, redundant checks are eliminated, and when a cybersecurity threat is detected, it can be precisely associated with a layer identifier, as described above.

[0055] Figure 4 This is an example flowchart 400 implemented according to an embodiment for reducing redundancy in inspecting cybersecurity threats in the container layer.

[0056] In S410, a difference output is generated between the first container image and the second container image. The first container image and the second container image are part of a container build. In an embodiment, the second container image is based on the first container image. For example, the first container image may be based on a base image. In some embodiments, the difference output is generated by generating instructions for the container engine, which are executed by the container engine. Figure 3 Examples of the above instructions are included.

[0057] In one embodiment, the difference output includes objects and object identifiers, such as what operating system (OS) packages were installed between the first and second container images, and what files were added, deleted, or changed. For example, an object can be a file, and the corresponding object identifier may include the directory path (or address) where the object is stored, and a filename or other identifier used to identify files within that directory. In some embodiments, a container repository (e.g., ECS) is accessed to retrieve the container image.

[0058] In S420, network security threats are checked in the first container image. In this embodiment, other objects with network security interests (also referred to as secure objects) are checked in the first container image. In this embodiment, network security threats include, but are not limited to, exposures, vulnerabilities, malware, ransomware, spyware, bots, weak passwords, exposed passwords, exposed certificates, expired certificates, misconfigurations, suspicious events, etc.

[0059] Secure objects such as files and folders can be inspected. These secure objects can be, for example, passwords stored in plaintext, passwords stored in plaintext, certificates, etc. As another example, in this embodiment, a signature is generated for the file, folder, etc., during the inspection. This signature is matched against another known signature. This known signature indicates a vulnerability. For example, a verification can be used to generate this signature. In this example, a file with a verification corresponding to a predetermined value is determined to have a predetermined known vulnerability.

[0060] In S430, network security threats are inspected in a second container image. The second container image is based on a first container image, meaning the first container image is a layer of the second container image. To effectively inspect the second container image, objects are identified from the difference output. In embodiments, inspecting the second container image includes identifying objects from the difference output and inspecting at least a portion of the objects from the difference output. In some embodiments, secure objects are inspected from the objects in the difference output. Secure objects may be, for example, files, folders, passwords stored in plaintext, passwords and certificates stored in plaintext, etc.

[0061] In S440, the detected cybersecurity threat is associated with the container image. In this embodiment, the detected security object is associated with the container image. Associating the cybersecurity threat with the container image includes: generating nodes representing the cybersecurity threat and nodes representing the container image in the security graph, and generating edges connecting the cybersecurity threat node to the container image node.

[0062] In some embodiments, in response to detecting a cybersecurity threat in the inspected container image but not in the container layer beneath the inspected container image, the detected cybersecurity threat is associated with the container image. In the above... Figure 1 In the example, if a cybersecurity threat is detected in the first image 141 but not in the second image 140-1, the detected cybersecurity threat is only associated with the first image 141.

[0063] In some embodiments, both container layers can be fully inspected. In such an embodiment, if a cybersecurity threat is detected in the bottom image (layer) but not in the top image (layer), the cybersecurity threat is associated with the bottom image. If a cybersecurity threat is detected in the top image but not in the bottom image, the cybersecurity threat is associated with the top image. If a cybersecurity threat is detected in both images, the cybersecurity threat is associated with the bottom image because the top image includes the bottom image. In such an embodiment, the detected cybersecurity threat is the same cybersecurity threat for both layers.

[0064] In S450, an inspection is performed to determine whether another image should be inspected. If "Yes", the execution can continue in S410 by selecting another image and generating differences between that other image and one of the first or second container images. If "No", the execution terminates.

[0065] By examining objects in the underlying layer and the differences between the underlying and upper layers, redundant checks are reduced, since the underlying layer is part of the upper layer.

[0066] Figure 5 This is an example flowchart 500 of a method for reducing redundancy in inspecting for cybersecurity threats in active containers, implemented according to an embodiment. This disclosure relates throughout to inspecting for cybersecurity threats in containers, container images, layers, etc. In this regard, it is worth noting that the inspection of other cybersecurity interests (i.e., security objects) is also within the scope of this disclosure, regardless of whether these objects are directly considered threats. For example, vulnerabilities, exposures, misconfigurations, and malware objects are all cybersecurity threats, while operating systems, applications, user accounts, etc., are examples of security objects of cybersecurity interests and can also be inspected by the inspector.

[0067] In S510, a difference output is generated between the first container image and the active container. The active container (also called the runtime layer) is deployed from the mount point of the first container image. In embodiments, the first container image comprises multiple layers. For example, the first container image may be based on a base image. In some embodiments, the difference output is generated by generating instructions for the container engine, which are then executed by the container engine. Figure 3 It contains examples of the above instructions.

[0068] In some embodiments, the difference output includes objects and object identifiers, such as what operating system (OS) packages were mounted between the first container image and the active container, and what files were added, deleted, or changed. For example, an object can be a file, and the corresponding object identifier may include the directory path (or address) where the object is stored, and a filename or other identifier used to identify files within that directory. In some embodiments, a container repository (e.g., ECS) is accessed to retrieve the container image. In some embodiments, the host VM can be accessed to read the container image (i.e., the active container) stored in the host VM's local cache.

[0069] In S520, cybersecurity threats are inspected in the first container image. In this embodiment, other objects with cybersecurity interests (also referred to as secure objects) are inspected in the first container image. In this embodiment, cybersecurity threats include, but are not limited to, exposures, vulnerabilities, malware, ransomware, spyware, bots, weak passwords, exposed passwords, exposed certificates, expired certificates, misconfigurations, suspicious events, etc.

[0070] Inspections can be performed on secure objects such as files and folders. Secure objects can be, for example, passwords stored in plaintext, passwords stored in plaintext, certificates, etc. As another example, in this embodiment, a signature is generated for the file, folder, etc., during the inspection. This signature is matched against another known signature. This known signature indicates a vulnerability. For example, a verification can be used to generate the signature. In this example, a file with a verification corresponding to a predetermined value is determined to have a predetermined known vulnerability.

[0071] In S530, cybersecurity threats are inspected in objects based on the generated differences. To effectively inspect the active container, objects are identified from the difference output. In embodiments, inspecting the active container includes identifying objects from the difference output and inspecting for cybersecurity threats in at least a portion of the objects from the difference output. In some embodiments, secure objects can be inspected in the objects from the difference output. Secure objects can be, for example, files, folders, passwords stored in plaintext, passwords stored in plaintext, and certificates, etc.

[0072] In S540, the detected cybersecurity threat is associated with a layer. In an embodiment, the detected security object is associated with a layer. The layer can be either a container image (i.e., a container layer) or an active container (i.e., a runtime layer). In an embodiment, associating a cybersecurity threat with a layer includes: generating nodes representing cybersecurity threats and nodes representing container layers in a security graph, and generating edges connecting the cybersecurity threat node and the container layer node.

[0073] In some embodiments, in response to detecting a cybersecurity threat in the runtime layer but not in the container layer where the runtime layer is deployed, the detected cybersecurity threat is associated with the container layer. Figure 1 In the example, if a cybersecurity threat is detected in image 140-N but not in container 150-1 from which it is deployed, then the detected cybersecurity threat is only associated with image 140-N.

[0074] In S550, an inspection is performed to determine whether another container should be inspected. If "Yes", execution can continue in S510 by selecting another container image and generating differences between that other container image and the runtime layer of the active container. If "No", execution terminates.

[0075] Redundant checks are reduced by examining the first container image and the objects in the difference output generated between the first container image and the runtime layer of the active container, since the first container image is included as part of the runtime layer.

[0076] Figure 6This is an example flowchart 600 of a layer-by-layer inspection method for operating system-level virtualization implemented according to an embodiment.

[0077] In S610, the first container image is inspected. As described above, a container is an operating system-level virtualization that includes an application and the dependencies required to run the application. In this embodiment, any one of the following is inspected in the first container image: network security objects and network security threats. In this embodiment, network security threats include, but are not limited to, exposures, vulnerabilities, malware, ransomware, spyware, bots, weak passwords, exposed passwords, exposed certificates, expired certificates, misconfigurations, suspicious events, etc.

[0078] Secure objects (such as files, folders, etc.) can be inspected. Secure objects can be, for example, passwords stored in plaintext, passwords stored in plaintext, certificates, etc. As another example, in this embodiment, a signature of the file, folder, etc., is generated during the inspection. This signature is matched against another known signature. This known signature indicates a vulnerability. For example, a verification can be used to generate the signature. In this example, a file with a verification corresponding to a predetermined value is determined to have a predetermined known vulnerability.

[0079] In S620, the second container image previously generated based on the first container image is examined. The second container image is a container layer located above the first container image. In an embodiment, the first container image is a base layer, and the second container image is an upper layer. In some embodiments, the second container image is the next consecutive layer relative to the first container image. The container image is generated as a result of the execution of build instructions, such as those executed by a container engine. In an embodiment, the first container image is a read-only image.

[0080] In S630, a check is performed to determine if a threat is detected in the second container image. In some embodiments, a check is performed to determine if a cybersecurity object that is not a cybersecurity threat is detected. If "No", execution continues in S670. If "Yes", execution continues in S640.

[0081] In S640, a check is performed to determine if a threat is detected in the first container image. In some embodiments, a check is performed to determine if a network security object that is not a network security threat is detected. If "No", execution continues in S660. If "Yes", execution continues in S650.

[0082] In S650, the detected object is associated with the first container image. If a secure object is detected in both images, the object's origin is in the first container image. This is because the second container image includes all objects from the first container image, as well as any subsequent modifications.

[0083] Therefore, security objects and threats appearing in both layers should be associated with the preceding layer, not the succeeding layer, because the object's origin must lie in the preceding layer. In some embodiments, when inspecting multiple layers (i.e., more than two layers), an object is associated with the lowest layer where it was detected. For example, if an object is detected in the second, third, and fourth layers, but not in the first layer (where the first layer is the base image and the fourth layer is the runtime layer), then the object should be associated with the second layer, because all succeeding layers include the second layer.

[0084] In some embodiments, associating a cybersecurity threat (or other object) with a layer includes: generating nodes representing cybersecurity threats, nodes representing container layers in a security graph, and generating edges that connect cybersecurity threat nodes to container layer nodes.

[0085] In S660, detected objects are associated with the second container image. If a secure object is detected in the second container image but not in the first container image, the object's origin is in the second container image. This is because the second container image includes all objects from the first container image, as well as any subsequent changes. Therefore, since the object's origin must be in the successor layer, secure objects, security threats, etc., that appear in the second container image but not the first container image should be associated with the successor layer, not the predecessor layer.

[0086] In some implementations, when inspecting multiple layers (i.e., more than two layers), an object is associated with the highest layer where it was detected. For example, if an object is detected in the third layer but not in the second or first layer (where the first layer is the base image and the third layer is the runtime layer), then the object should be associated with the third layer because no cybersecurity threats are included in any of the preceding layers.

[0087] In some embodiments, associating a cybersecurity threat (or other object) with a layer includes generating nodes representing cybersecurity threats, nodes representing container layers, and generating edges that connect cybersecurity threat nodes to container layer nodes in the security graph.

[0088] Figure 7 This is an example flowchart 700 of a method for tracing cloud objects to code objects by detecting cybersecurity objects in an operating system-level virtualization software product, implemented according to an embodiment. In some embodiments, the computing environment (e.g., a cloud computing environment) includes multiple code objects (e.g., objects stored in a version control system (VCS)). An example of such a VCS is implemented using GitHub®.

[0089] Inspecting each of multiple code objects is resource-intensive. Therefore, it is advantageous to trace deployed code (such as software containers) back to code objects and then only inspect the code objects corresponding to virtualized instances, cloud objects, etc., deployed in a cloud computing environment. This reduces resource consumption (such as processor utilization, memory utilization, etc.) because fewer code objects need to be inspected, while still maintaining a reasonable level of security.

[0090] In S710, code objects are detected. In this embodiment, code objects are detected within an operating system-level virtualized software product. Operating system-level virtualization is also known as software containerization, and is implemented, for example, by software container platforms such as Docker®, Kubernetes®, etc.

[0091] In some embodiments, the identifier of the code object is detected in the operating system-level virtualization software product. In various embodiments, the code object is executable code, declarative code, machine-executable code, etc. In some embodiments, the software product includes container images (e.g., Docker® images), container configuration files, Dockerfile®, logs, metadata, or combinations thereof, related to software container creation and execution.

[0092] In various embodiments, the inspection controller is configured to access a software product of a software container deployed in a production environment (e.g., a cloud computing environment). In some embodiments, the inspection controller is configured to inspect at least one code object within the software product. In certain embodiments, the inspection controller is configured to inspect the software product by parsing and analyzing code segments to detect code objects.

[0093] In S720, the location of the code object is determined. In various embodiments, the inspection controller is configured to determine the location of the detected code object. In some embodiments, the inspection controller is configured to determine the location of the detected code object by detecting its location in container images, Docker® images, container configuration files, Dockerfiles®, and combinations thereof. In some embodiments, the location is stored as a regular expression in a file.

[0094] In one embodiment, the inspection controller is configured to detect the location of code objects within command instructions in a container configuration file (e.g., a Dockerfile®). For example, in one embodiment, if the command instruction declares " COPY.src / app / src ",but" src "The directory is located inside the container" / app / src "In the file."

[0095] In various embodiments, the inspection controller is configured to determine the location of detected code objects by detecting specific path locations of code objects in container environment variables, container configuration files (e.g., Dockerfile®), combinations thereof, etc. In some embodiments, the inspection controller is configured to initiate an inspection of a container image (e.g., a Docker® image) to determine the location of the code objects.

[0096] In the embodiments, this location is a network storage device, a cloud computing storage device, a version control system, a code repository, or a combination thereof.

[0097] In S730, the location of the code object is accessed. In various embodiments, the inspection controller is configured to access a specific location of the code object. In various embodiments, the inspection controller is configured to authenticate the provided certificate to access the location of the code object. In some embodiments, the inspection controller is configured to use an authentication token to access the location of the code object.

[0098] In some embodiments, the code object is retrieved from the location where it is stored. In an embodiment, the inspection controller is configured to provide the inspector with access to the code object, copies of the code object, etc. According to an embodiment, the inspector is configured to inspect the code object for cybersecurity objects (e.g., using static analysis).

[0099] In S740, a cybersecurity object is detected in the code object. In various embodiments, the inspection controller is configured to assign an inspector to inspect cybersecurity objects within the code object. In embodiments, the inspector is configured to detect cybersecurity objects associated with cybersecurity threats. In embodiments, cybersecurity threats include, but are not limited to, exposures, vulnerabilities, malware, ransomware, spyware, bots, weak passwords, exposed passwords, exposed certificates, expired certificates, misconfigurations, suspicious events, etc.

[0100] In this embodiment, the cybersecurity threat is represented by multiple cybersecurity objects, i.e., a toxic combination of multiple cybersecurity objects. In some embodiments, the multiple cybersecurity objects include a first type of cybersecurity object (e.g., weak password) and a second type of cybersecurity object (e.g., misconfiguration).

[0101] In S750, remediation actions are initiated. In one embodiment, remediation actions are initiated based on the detection of a cybersecurity object. In another embodiment, the inspection controller is configured to initiate remediation actions in response to the detection of a cybersecurity object in a code object associated with a software product deployed in an operating system-level virtualization environment in a cloud computing environment. In some embodiments, the inspection controller is configured to generate remediation actions to remedy the cybersecurity threat indicated by the cybersecurity object. In some embodiments, remediation actions include any of the following: deleting a vulnerable container image (e.g., a Docker image), enforcing network policies to isolate software containers, restricting the capabilities of exposed software containers, restoring backups of software container data, initiating a recovery of the software container, authenticating software container images, and combinations thereof.

[0102] Figure 8 This is an example flowchart 800 of a method for improving software container inspection using fingerprint matching, implemented according to an embodiment. Inspecting cybersecurity objects within software containers is challenging because containers provide a dynamic environment and consist of complex architectures, making threat detection difficult. Therefore, it is advantageous to inspect the configuration files of the software containers, determine whether the configuration files match based on the fingerprint of each file, and then inspect the individual software containers (or fewer than the total number of containers) that match the configuration files. This reduces resource usage (e.g., processor utilization, memory utilization, etc.) because it narrows down the range of multiple configuration files of the containers that need to be inspected.

[0103] In S810, multiple configuration files are inspected. In one embodiment, the configuration file is a software container configuration file used to generate operating system-level virtualization. In some embodiments, the configuration file is a Dockerfile®, which is a file including code, code objects, commands, and combinations thereof. In one embodiment, the inspection controller is configured to assign an inspector that is configured to inspect the code, code objects, commands, and combinations thereof used to build a software container image (e.g., a Docker® image). In various embodiments, the inspection controller, inspector, etc., are configured to inspect multiple configuration files.

[0104] In S820, a first configuration file is parsed. In some embodiments, the first configuration file is parsed to detect a first plurality of commands. In some embodiments, a first configuration file among a plurality of configuration files is selected for inspection. In some embodiments, a plurality of first configuration files are parsed. In some embodiments, the configuration file (e.g., a container configuration file) is a Dockerfile®, which is a file including code, code objects, commands, and combinations thereof.

[0105] In this embodiment, the command is an instruction located in the container configuration file that defines the steps for building the container image. For example, in this embodiment, " FROM ubuntu: 24.05 This is a command instruction that specifies that a base image must be used to generate a new container image. In some embodiments, other commands include " FROM " RUN " COPY " ADD "and its combinations, etc."

[0106] In some embodiments, a first configuration file is parsed to detect code objects, code, commands, combinations thereof, etc. In some embodiments, a specific command, a specific command type, etc., is detected in the first configuration file.

[0107] In S830, a first fingerprint is generated. In some embodiments, the first fingerprint is generated based on a first plurality of detected commands. In an embodiment, the inspection controller is configured to generate the first fingerprint.

[0108] In various embodiments, the first fingerprint is associated with a configuration file. In some embodiments, the first fingerprint is an identifier generated based on the configuration of commands (e.g., the number of commands, the type of each command, the order of commands in the configuration file, the sequence of commands, combinations of commands, and the formal parameters of the commands, combinations thereof, etc.). In various embodiments, the first fingerprint is an identifier based on the configuration of multiple commands detected in the configuration file.

[0109] In the embodiments, command type refers to the same command, commands that provide the same function, commands that provide the same action, etc.

[0110] For example, in an embodiment, commands of the same type include the same commands (e.g., " COPY. / app "and" COPY. / file6 For example, in an embodiment, commands with the same command type include "". COPY . / configfile3 "and" ADD "https: / / sample6.com / file.24 / app7" is used because both commands provide similar functionality for adding files, Uniform Resource Locators (URLs), and combinations thereof to container images.

[0111] In S840, a second configuration file is parsed. In an embodiment, the second configuration file is parsed to detect a second plurality of commands. In some embodiments, a second configuration file is selected from a plurality of configuration files for inspection. In some embodiments, a plurality of second configuration files are parsed. In some embodiments, the configuration file (e.g., a container configuration file) is a Dockerfile®, which is a file including code, code objects, commands, and combinations thereof.

[0112] In this embodiment, the command is an instruction located in the container file that defines the steps for building the container image. For example, in this embodiment, " FROM ubuntu: 24.05 "This is a command instruction that specifies that a base image must be used to generate a new container image. In some embodiments, other commands include " FROM " RUN " COPY " ADD "etc., and their combinations, etc."

[0113] In some embodiments, a second configuration file is parsed to detect code objects, code, commands, combinations thereof, etc. In some embodiments, a specific command, a specific command type, etc., is detected in a first configuration file.

[0114] In S850, a second fingerprint is generated. In one embodiment, the second fingerprint is generated based on a second plurality of detected commands. In various embodiments, the inspection controller is configured to generate the second fingerprint.

[0115] In various embodiments, the second fingerprint is associated with a configuration file. In some embodiments, the second fingerprint is an identifier generated based on command configuration (e.g., the number of commands, the type of each command, the order of commands in the configuration file, a sequence of commands, a combination of commands, the formal parameters of the commands, combinations thereof, etc.). In various embodiments, the second fingerprint is an identifier based on the configuration of multiple commands detected in the configuration file.

[0116] In the embodiments, command type refers to commands that are the same, provide the same function, or provide the same action.

[0117] For example, in an embodiment, commands of the same type include the same commands, such as " COPY. / app "and" COPY. / file7 For example, in an embodiment, commands with the same command type include " COPY . / configfile3 The commands "ADDhttps: / / sample6.com / file.24 / app7" are used because both commands provide similar functionality to add files, Uniform Resource Locators (URLs), and combinations thereof to a container image.

[0118] In S860, a check is performed to determine if a match is detected. According to an embodiment, if "yes," i.e., a match is detected, execution continues in S870. In some embodiments, if a mismatch is detected (i.e., no match is detected), execution continues in S880 using another second fingerprint, wherein the other fingerprint is generated based on another configuration file (e.g., a Dockerfile®), and that other configuration file is not the second configuration file.

[0119] In S870, the first configuration file is checked. In this embodiment, it is advantageous to check the first configuration file after a match is detected because the scope of checking multiple configuration files of the container is narrowed when a matching configuration file is detected. In this embodiment, this reduces the resource usage (e.g., processor utilization, memory utilization, storage device utilization) required to check the container's configuration files.

[0120] In some embodiments, network security objects are inspected in a first profile. In various embodiments, in response to a detected match, the inspection controller is configured to trigger an inspection of the first profile. In some embodiments, network security objects are associated with network security threats. In some embodiments, network security threats include, but are not limited to, exposures, vulnerabilities, malware, ransomware, spyware, bots, weak passwords, exposed passwords, exposed certificates, expired certificates, misconfigurations, suspicious events, etc.

[0121] In some embodiments, a remediation action is initiated in response to the detection of a cybersecurity object in a first profile. In some embodiments, the inspection controller is configured to generate a remediation action to remedy the cybersecurity threat indicated by the cybersecurity object. In some embodiments, the remediation action includes deleting vulnerable container files or container images, enforcing network policies to isolate software containers, restricting the ability to expose containers, restoring data backups from containers, initiating software container recovery, or combinations thereof.

[0122] Figure 9 This is an example schematic diagram of an inspection controller 260 according to an embodiment. The inspection controller 260 includes processing circuitry 910 coupled to a memory 920, a storage device 930, and a network interface 940. In this embodiment, components of the inspection controller 260 may be communicatively connected via a bus 950.

[0123] The processing circuitry 910 can be implemented as one or more hardware logic components and circuits. For example, but not limited to, exemplary types of hardware logic components that can be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), graphics processing units (GPUs), tensor processing units (TPUs), general-purpose microprocessors, microcontrollers, digital signal processors (DSPs), and any other hardware logic components capable of performing computations or other information manipulations.

[0124] The memory 920 may be volatile (e.g., random access memory, etc.), non-volatile (e.g., read-only memory, flash memory, etc.) or a combination thereof.

[0125] In one configuration, software for implementing one or more embodiments disclosed herein may be stored in storage device 930. In another configuration, memory 920 is configured to store such software. Software should be interpreted broadly as any type of instruction, whether referred to as software, firmware, middleware, microcode, hardware description language, or others. Instructions may include code (e.g., source code format, binary code format, executable code format, or any other suitable code format). When the instructions are executed by processing circuitry 910, they cause processing circuitry 910 to perform the various processes described herein.

[0126] Storage device 930 may be a magnetic storage device, an optical storage device, etc., and may be implemented as, for example, flash memory or other storage technologies, or any other medium that can be used to store the required information.

[0127] Network interface 940 allows inspection controller 260 to communicate with, for example, security database 240, inspector 270, container engine 210, etc.

[0128] It should be understood that the embodiments described herein are not limited to those described herein. Figure 9 The specific architecture shown can be used with other architectures without departing from the scope of the disclosed embodiments. Similarly, Figure 9 The architecture shown can be used to deploy inspector 270, container engine 210, virtual machine 230, etc.

[0129] The various embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof. Furthermore, the software is preferably implemented as an application tangibly embodied in a program storage unit or computer-readable medium consisting of components or combinations of devices and / or devices. This application can be uploaded to and executed by a machine including any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (“CPUs”), memory, and input / output interfaces. The computer platform may also include an operating system and microinstruction code. The various processes and functions described herein may be part of microinstruction code executable by the CPU or part of an application program, or any combination thereof, whether or not such a computer or processor is explicitly shown. Furthermore, various other peripheral units may be connected to the computer platform, such as additional data storage units and printing units. Additionally, a non-transitory computer-readable medium is any computer-readable medium other than transient propagation signals.

[0130] All examples and conditional language described herein are intended for educational purposes to help readers understand the principles of the disclosed embodiments and the concepts contributed by the inventors to further develop the art, and should be interpreted as not being limited to these specifically referenced examples and conditions. Furthermore, all statements and specific examples of the principles, aspects, and embodiments of the disclosed embodiments described herein are intended to cover their structural and functional equivalents. Moreover, such equivalents include currently known equivalents as well as those developed in the future, i.e., any element developed that performs the same function, regardless of its structure.

[0131] It should be understood that any reference to elements in this document using names such as "first," "second," etc., does not generally restrict the number or order of these elements. Rather, these names are generally used as a convenient way to distinguish two or more elements or instances of elements. Therefore, mentioning the first and second elements does not imply that only two elements can be used there, nor does it imply that the first element must precede the second element in some way. Furthermore, unless otherwise stated, a group of elements includes one or more elements.

[0132] As used herein, the phrase “at least one” is followed by a list of items, meaning that any one of the listed items can be used alone, or any combination of two or more of the listed items can be used. For example, if a system is described as including “at least one of A, B, and C”, then the system can include only A; only B; only C; 2A; 2B; 2C; 3A; a combination of A and B; a combination of B and C; a combination of A and C; a combination of A, B, and C; a combination of 2A and C; a combination of A, 3B, and 2C; and so on.

Claims

1. An improved method for inspecting software containers deployed in a cloud computing environment, comprising: Multiple configuration files are detected, each configuration file corresponding to at least one software container image, the software container image corresponding to a software container deployed in the cloud computing environment; Parse the first configuration file among the plurality of configuration files to detect the first plurality of commands; A first fingerprint is generated based at least on the detected first plurality of commands; Parse the second configuration file among the multiple configuration files to detect a second set of commands; A second fingerprint is generated based at least on the detected second or more commands; In response to the detection of a match based on the first fingerprint and the second fingerprint, it is determined that the first profile matches the second profile; In response to a mismatch detected based on the first fingerprint and the second fingerprint, it is determined that the first configuration file and the second configuration file do not match; and In response to determining that the first profile matches the second profile, network security objects are checked in the first profile.

2. The method according to claim 1, further comprising: When it is determined that the first configuration file does not match the second configuration file, another second fingerprint is generated.

3. The method according to claim 2, further comprising: Another second fingerprint is generated based on a different configuration file that is not the second configuration file.

4. The method according to claim 1, further comprising: The first fingerprint is generated based on the command, the number of commands, the command sequence, the command configuration, the command actual parameters, the command formal parameters, and any combination thereof.

5. The method according to claim 1, further comprising: A second fingerprint is generated based on commands, the number of commands, command sequences, command configurations, and any combination thereof.

6. The method according to claim 1, further comprising: The first configuration file is parsed to detect code objects, code, commands, and any combination thereof.

7. The method according to claim 1, further comprising: The second configuration file is parsed to detect code objects, code, commands, and any combination thereof.

8. The method according to claim 1, further comprising: Detecting cybersecurity objects, wherein the cybersecurity objects are associated with cybersecurity threats.

9. The method according to claim 8, wherein, The cybersecurity threats include any of the following: exposure, vulnerability, malware, ransomware, spyware, misconfiguration, and any combination thereof.

10. A non-transitory computer-readable medium storing a set of instructions for improving the inspection of software containers deployed in a cloud computing environment, the set of instructions comprising: One or more instructions, when executed by one or more processing circuits of the device, cause the device to: Multiple configuration files are detected, each configuration file corresponding to at least one software container image, the software container image corresponding to a software container deployed in the cloud computing environment; Parse the first configuration file among the plurality of configuration files to detect the first plurality of commands; A first fingerprint is generated based at least on the detected first plurality of commands; Parse the second configuration file among the multiple configuration files to detect a second set of commands; A second fingerprint is generated based at least on the detected second or more commands; In response to the detection of a match based on the first fingerprint and the second fingerprint, it is determined that the first profile matches the second profile; In response to a mismatch detected based on the first fingerprint and the second fingerprint, it is determined that the first configuration file and the second configuration file do not match; and In response to determining that the first configuration file matches the second configuration file, a network security object is checked in the first configuration file.

11. A system for improving the inspection of software containers deployed in a cloud computing environment, comprising: One or more processing circuits are configured as follows: Multiple configuration files are detected, each configuration file corresponding to at least one software container image, the software container image corresponding to a software container deployed in the cloud computing environment; Parse the first configuration file among the plurality of configuration files to detect the first plurality of commands; A first fingerprint is generated based at least on the detected first plurality of commands; Parse the second configuration file among the multiple configuration files to detect a second set of commands; A second fingerprint is generated based at least on the detected second or more commands; In response to the detection of a match based on the first fingerprint and the second fingerprint, it is determined that the first profile matches the second profile; In response to a mismatch detected based on the first fingerprint and the second fingerprint, it is determined that the first configuration file and the second configuration file do not match; and In response to determining that the first configuration file matches the second configuration file, a network security object is checked in the first configuration file.

12. The system according to claim 11, wherein, The one or more processing circuits are further configured to: When it is determined that the first configuration file does not match the second configuration file, another second fingerprint is generated.

13. The system according to claim 12, wherein, The one or more processing circuits are further configured to: Another second fingerprint is generated based on a different configuration file that is not the second configuration file.

14. The system according to claim 11, wherein, The one or more processing circuits are further configured to: The first fingerprint is generated based on the command, the number of commands, the command sequence, the command configuration, the command actual parameters, the command formal parameters, and any combination thereof.

15. The system according to claim 11, wherein, The one or more processing circuits are further configured to: A second fingerprint is generated based on commands, the number of commands, command sequences, command configurations, and any combination thereof.

16. The system according to claim 11, wherein, The one or more processing circuits are further configured to: Parse the first configuration file to detect code objects, code, commands, and any combination thereof.

17. The system according to claim 11, wherein, The one or more processing circuits are further configured to: The second configuration file is parsed to detect code objects, code, commands, and any combination thereof.

18. The system according to claim 11, wherein, The one or more processing circuits are further configured to: Detecting cybersecurity objects, wherein the cybersecurity objects are associated with cybersecurity threats.

19. The system according to claim 18, wherein, The cybersecurity threats include any of the following: exposure, vulnerability, malware, ransomware, spyware, misconfiguration, and any combination thereof.

Images