System and method for service profile and runtime detection rule generation based on deep code analysis

[0001] The present disclosure relates generally to the field of cybersecurity and in particular to automatic implementation of runtime cybersecurity rules.

[0002] A software service refers to a software application or component that provides specific functionality and is made available to users over a network. Unlike traditional software, which is typically installed on individual computers, a software service is often accessed remotely, typically via a web interface or API, and does not require local installation or maintenance by the end-user. This model enables scalability, central management, and frequent updates, which are particularly well-suited to modern, dynamic business environments.

[0003] In a cloud computing environment, software services are usually deployed on virtualized infrastructure managed by cloud providers such as Amazon® Web Services, Microsoft® Azure, or Google® Cloud. The deployment process typically involves packaging the software into containers or virtual machines, which are then orchestrated and managed using platforms like Kubernetes. These services may be designed as monoliths or broken down into microservices that communicate over the network. Cloud environments offer significant advantages, including elasticity, geographic distribution, and robust failover capabilities.

[0004] Despite these benefits, deploying software services in the cloud introduces several cybersecurity challenges. One major concern is the expanded attack surface that comes from exposing services over the internet. This makes them susceptible to threats such as distributed denial-of-service attacks, unauthorized access attempts, and API abuse. The use of shared infrastructure also raises questions about data isolation and the potential for cross-tenant breaches. Misconfigurations in cloud environments, such as improperly secured storage buckets or overly permissive access controls, are another frequent vulnerability. Additionally, the dynamic nature of cloud environments, with constantly changing resources and endpoints, complicates the tasks of monitoring and maintaining security controls consistently on such software services. These issues underscore the importance of a thorough understanding of the risks associated with cloud-based software services.

[0005] It would therefore be advantageous to provide a solution that would overcome the challenges noted above.

[0006] A summary of several example embodiments of the disclosure follows. This summary is provided for the convenience of the reader to provide a basic understanding of such embodiments and does not wholly define the breadth of the disclosure. This summary is not an extensive overview of all contemplated embodiments, and is intended to neither identify key or critical elements of all embodiments nor to delineate 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 is presented later. For convenience, the term “some embodiments” or “certain embodiments” may be used herein to refer to a single embodiment or multiple embodiments of the disclosure.

[0007] A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.

[0008] In one general aspect, the method may include detecting a code object of a cloud computing environment, the code object utilized to deploy a resource in the cloud computing environment. The method may also include performing static analysis on the code object. The method may furthermore include generating a behavior baseline of the resource based on a result of the static analysis of the code object. The method may in addition include generating a runtime rule based on the behavior baseline. The method may moreover include applying the generated runtime rule on an event related to the resource. The method may also include detecting a suspicious activity respective of the resource based on an application of the generated runtime rule on the event. 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 methods.

[0009] Implementations may include one or more of the following features. The method may include: detecting a software service deployed in the cloud computing environment, the software service including at least the resource; and generating a service behavior baseline based at least on the behavior baseline of the resource. The method may include: detecting the suspicious activity based on the service behavior baseline. The method may include: deploying a runtime sensor on the resource in the cloud computing environment, and configuring the runtime sensor to apply the generated runtime rule. The method may include: detecting the event by the runtime sensor. The method may include: detecting the event in a log of the cloud computing environment. The method may include: detecting the event in the log, the event including a data record having an identifier of the resource; determining that the suspicious activity is a cybersecurity threat; and initiating a mitigation action based on the cybersecurity threat. The method may include: generating a representation in a security database for each of: the code object, and the resource. The method may include: deploying a runtime sensor including the generated runtime rule on each resource in the cloud computing environment having a representation in the security database which is connected to the representation of the code object. The method may include: initiating a remediation action based on the detected suspicious activity. The method may include: updating the behavior profile in response to detecting a plurality of events in an event log, each event of the plurality of events indicating an allowable action initiated by the resource. Implementations of the described techniques may include hardware, a method or process, or a computer tangible medium.

[0010] In one general aspect, a non-transitory computer-readable medium may include one or more instructions that, when executed by one or more processing circuitries of a device, cause the device to: detect a code object of a cloud computing environment, the code object utilized to deploy a resource in the cloud computing environment; perform static analysis on the code object; generate a behavior baseline of the resource based on a result of the static analysis of the code object; generate a runtime rule based on the behavior baseline; apply the generated runtime rule on an event related to the resource; detect a suspicious activity respective of the resource based on an application of the generated runtime rule on the event. 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 methods.

[0011] In one general aspect, a system may include a processing circuitry. The system may also include a memory, the memory containing instructions that, when executed by the processing circuitry, configure the system to: The system detect a code object of a cloud computing environment, the code object utilized to deploy a resource in the cloud computing environment. The system may in addition perform static analysis on the code object. The system may moreover generate a behavior baseline of the resource based on a result of the static analysis of the code object. The system may also generate a runtime rule based on the behavior baseline. The system may furthermore apply the generated runtime rule on an event related to the resource. The system may in addition detect a suspicious activity respective of the resource based on an application of the generated runtime rule on the event. 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 methods.

[0012] Implementations may include one or more of the following features. The system where the memory contains further instructions which when executed by the processing circuitry further configure the system to: detect a software service deployed in the cloud computing environment, the software service including at least the resource; and generate a service behavior baseline based at least on the behavior baseline of the resource. The system where the memory contains further instructions which when executed by the processing circuitry further configure the system to: detect the suspicious activity based on the service behavior baseline. The system where the memory contains further instructions which when executed by the processing circuitry further configure the system to: deploy a runtime sensor on the resource in the cloud computing environment, and configure the runtime sensor to apply the generated runtime rule. The system where the memory contains further instructions which when executed by the processing circuitry further configure the system to: detect the event by the runtime sensor. The system where the memory contains further instructions which when executed by the processing circuitry further configure the system to: detect the event in a log of the cloud computing environment. The system where the memory contains further instructions which when executed by the processing circuitry further configure the system to: detect the event in the log, the event including a data record having an identifier of the resource; determine that the suspicious activity is a cybersecurity threat; and initiate a mitigation action based on the cybersecurity threat. The system where the memory contains further instructions which when executed by the processing circuitry further configure the system to: generate a representation in a security database for each of: the code object, and the resource. The system where the memory contains further instructions which when executed by the processing circuitry further configure the system to: deploy a runtime sensor including the generated runtime rule on each resource in the cloud computing environment having a representation in the security database which is connected to the representation of the code object. The system where the memory contains further instructions which when executed by the processing circuitry further configure the system to: initiate a remediation action based on the detected suspicious activity. The system where the memory contains further instructions which when executed by the processing circuitry further configure the system to: update the behavior profile in response to detecting a plurality of events in an event log, each event of the plurality of events indicating an allowable action initiated by the resource. Implementations of the described techniques may include hardware, a method or process, or a computer-tangible medium.

[0030] It is important to note that the embodiments disclosed herein are only examples of the many advantageous uses of the innovative teachings herein. In general, statements made in the specification of the present application do not necessarily limit any of the various claimed embodiments. Moreover, some statements may apply to some inventive features but not to others. In general, unless otherwise indicated, singular elements may be in plural and vice versa with no loss of generality. In the drawings, like numerals refer to like parts through several views.

[0031] FIG. 1 is a network diagram 100 of a monitored cloud environment utilizing infrastructure as code (IaC) utilized to describe the various embodiments.

[0032] A client device 110 generates a configuration code file 120 based on input from one or more users (e.g., software programmers). While a client device 110 is shown here for simplicity and pedagogical purposes, it should be readily apparent that the configuration code may be generated by a client device, a virtual workload in a cloud environment, and the like. Likewise, the configuration code may be generated by multiple different client devices, a single client device may generate multiple configuration codes, or any combination of these scenarios.

[0033] The configuration code file 120 may be implemented in a declaratory computer language. In a declaratory computer language, a user declares resources they would like to have as code objects, and an orchestrator 130 deploys instances in the cloud environment based on the declarations. In certain embodiments, multiple configuration code files 120 may be utilized. For example, a user may operate multiple cloud environments, each with its own configuration code. As another example, a user can declare a first resource type for a first cloud environment and for a second cloud environment in a first configuration code file, and a second resource type for the first cloud environment and the second cloud environment in a second configuration code file.

[0034] An orchestrator 130 receives the configuration code file 120. The orchestrator 130 configures a cloud environment 140 (production cloud environment) to deploy various instances based on the declarations of the configuration code file. An instance is a virtual workload, and may be, for example, a virtual machine 142, container 144, or serverless function 146. The orchestrator 130 may perform deployment by assigning (also known as provisioning) cloud environment resources, such as processors, memory, storage, etc. to the virtual instance. The deployed instances are also known as a production environment. The configuration code may be implemented in a development (dev) environment, which may also be a cloud computing environment.

[0035] In some embodiments, a plurality of instances may be associated with a first object (not shown) of the configuration code file 120. This provides an advantage where it is required to deploy multiple instances that share similar configurations, such as web servers providing access to a website. Rather than configure each instance (also referred to as a workload) manually and individually, the orchestrator is able to deploy a number of the same instance based on the configuration code file 120.

[0036] In some embodiments, the orchestrator 130 may configure a cloud-native orchestrator (not shown) in the cloud environment 140 to deploy the instances. This may be advantageous, for example, where instances need to be deployed in different cloud environments. For example, the same instances may be deployed simultaneously on Google® Cloud Platform (GCP), Amazon® Web Services (AWS), or Microsoft® Azure. This can be achieved by configuring the orchestrator 130 to generate native instructions for a cloud native orchestrator in each environment to deploy such instances. The native instructions may be generated by the orchestrator 130, which generates the instruction based on objects declared in the configuration code file 120. This method of deploying instances decreases errors by eliminating the need for a user to manually deploy each instance and configure each instance separately, and is also a faster method of deployment. In the example above a first load balancer may be deployed in a first cloud computing environment, and a second load balancer may be deployed in a second cloud computing environment, each cloud computing environment having different infrastructure from each other, wherein the first load balancer and the second load balancer are deployed based on the same code object from a configuration code file.

[0037] A second cloud environment 150 may be utilized for inspecting the first cloud environment 140 and generating security risk assessments with respect to instances in the first cloud environment 140. The second cloud environment 150 may include one or more inspectors, such as inspector 160. An inspector is a workload which inspects another workload for objects, such as secrets, files, folders, registry values, and so on. Each inspector may be configured to inspect for one or more different object types.

[0038] For example, an inspector (or other workload, not shown here) may generate a request to inspect the virtual machine 142. The request may be received through an API (not shown) of the first cloud environment 140. A snapshot may be generated of a volume of the virtual machine 142 and sent to the second cloud environment 150. A container may be deployed in the second cloud environment and attached to a volume generated in the second cloud environment based on the received snapshot. The attached volume is then accessed by the inspector 160 to inspect the volume for a specific object type(s). The inspector 160 may generate data for storing on a security graph 170.

[0039] A security graph 170 may be stored on a graph database. The security graph includes a plurality of nodes, at least a portion of which correspond to a resource or a principal. A resource may be a workload, such as a virtual machine, serverless function, container, and the like. A principal may be a user group, user account, service account, and the like. Generally, a principal acts on a resource to achieve a result. The security graph may further include enrichment nodes, which may indicate certain functionalities, network access, and the like. For example, an enrichment node may be used to indicate public internet access. Thus, a node corresponding to a workload which has public internet access, or can be accessed through a public internet connection, would be connected to an internet access node.

[0040] A code inspector 180 is further deployed in the second cloud environment 150. In an embodiment, more than one code inspector may be deployed. Configuration code may be generated by multiple different types of platforms, such as Pulumi®, Terraform®, and the like. For example, a first code inspector may inspect configuration code generated using Pulumi®, while a second code inspector may inspect configuration code generated using Terraform®. In an embodiment, the code inspector 180 is realized as a workload configured to receive configuration code and inspect the code to find one or more types of code objects. A type of code object may be, for example, a secret (such as public key, private key), resource type, policy identifier, role identifier, status of flags, and the like. A flag status may indicate that a certain object is allowed to perform certain actions, such as network access, or assume a role, such as an administrator role (in the case of a user or service account). The code inspector 180 may attempt to match the detected object(s) to one or more nodes in a security graph. This is discussed in more detail with respect to FIG. 2 below. Code inspectors are discussed in more detail in U.S. Non-Provisional patent application Ser. No. 17/532,557 the entire contents of which are incorporated herein by reference.

[0041] The second cloud environment 150 further includes a policy engine 190. A policy engine 190 may be implemented as a workload, such as a virtual machine or container. The policy engine 190 may include a plurality of rules, each of which may include a condition and an action. A rule may be implemented, for example, as an ‘if-then’ statement. In an embodiment, the policy engine 190 may periodically check if one or more of the rules are violated by a workload or account in the first cloud computing environment 140. The policy engine 190 may further include policies which indicate permissions associated with workloads, accounts, or both. For example, a policy may state that a user account belonging to a first user group is authorized to access the VM 142. In an embodiment, the policy engine 190 may be implemented in the first cloud environment 140, and accessible by the second cloud environment 150.

[0042] The configuration code 120 may be further accessed by a stage environment orchestrator 130-S. While this embodiment utilizes an orchestrator 130 for a production cloud environment 140, and a stage environment orchestrator 130-S for a staging cloud environment 140-S, it should be apparent that a single orchestrator may be used for both the production and stage environments. A staging cloud environment 140-S is a cloud computing environment which is practically identical to the production cloud environment 140, other than the presence of test workloads, or other changes which are tested in order to later deploy them in the production environment. A staging environment is used for testing purposes, for example, to determine if a workload can handle a volume of expected traffic. Typically, workloads are deployed in a staging environment prior to deployment in a production environment, so as to detect any issues which the workload may cause in the production environment.

[0043] For example, a second VM 143-S is a workload which is deployed in the staging cloud environment 140-S, but not yet deployed in the production cloud environment 140. A first VM 142-S is a workload identical to VM 142, a container 144-S is a workload identical to the container 144 deployed in the production cloud environment 140, and a serverless function 146-S is identical to the serverless function 146.

[0044] It is common that workloads in the production environment 140 trigger errors, based for example, on policies of the production cloud environment 140. A policy engine 190 may allow users to configure an exception to an error. For example, if a VM 142 triggers an error (i.e., violates a policy), an exception may be added to the policy engine 190, to ignore the error when applied to the VM 142. An exception may be implemented as a rule in the policy engine 190. However, as the exception is specific to the VM 142, the staging environment VM 142-S, which is identical to the VM 142, would trigger an error, based on violating the same policy. This can be overcome by representing configuration code objects, objects of the staging environment 140-S, and objects of the production environment 140, all in a security graph 170. An example for such a method is discussed in more detail with respect to FIG. 8 below.

[0045] FIG. 2 is an example flowchart 200 of a method for inspecting configuration code based on a security graph, implemented in accordance with an embodiment. The method provides the ability to inspect configuration code in a development (dev) environment based on a security graph which is generated at least in part based on a production environment. The production environment is rarely, if at all, identical to the environment which is deployed initially by code. This is due to, for example, upgrades and patches implemented in the production environment. As production teams and dev teams are usually not the same, there is a phenomenon known as configuration drift, which describes how the production environment, over time, ‘drifts’ further away from the initial configuration code design.

[0046] The security graph may be generated based both off of the code and the production environment. By inspecting the configuration code based on a security graph generated from data from the production environment, insight can be gained and deployment issues may be caught early on, for example, to identify instances which if deployed based on a current version of configuration code would include a version of software which the production environment has already upgraded to a newer version. The method may be performed by a configuration code inspector, such as the code inspector 180.

[0047] At S210, configuration code is received by, for example, a configuration code inspector. The configuration code includes a plurality of code objects, at least a portion of which correspond to instances which are intended to be deployed in a cloud computing environment. The configuration code may be scanned or otherwise inspected as a textual object, meaning it can be searched for regular expressions (regex), strings, and the like.

[0048] At S220, a first code object is extracted from the received code. Extracting a code object may include, for example, searching the text of a configuration code file for one or more predetermined strings. For example, a code object may be a text field identifying a type of workload, a name of a workload, a network address, a name in a namespace, a role, a permission, and the like.

[0049] At S230, a security graph is traversed to detect if a node in the graph corresponds to the extracted first object. Traversing the security graph may include, for example, sending a request through an API of a graph database hosting the security graph to search the graph for a string or value corresponding to the first object. For example, if the first object is a secret, such as a private key, the security graph may be traversed to determine if there is a node which represents the matching public key. In some embodiments, a query directed at the security graph may include a plurality of clauses, for example, to search for container nodes which are attached to a node which represents the public key. It is worth noting that detecting a node which corresponds to the extracted first object may include nodes which are not a node representing a workload corresponding to the first object.

[0050] For example, executing code of the first object may result in deploying a first load balancer in a virtual private cloud (VPC). Once the first load balancer is deployed, a node may be generated in a security graph to represent the first load balancer and would be connected to a node representing the VPC. An advantage of the disclosed method is that attributes of the first object may be detected in the graph, which allows to detect nodes prior to the generation of the actual workload. In other words, a security risk may be detected in a workload prior to it being deployed. In this example, as the code of the first object includes instructions to deploy in the VPC, the VPC node may be detected, and from there an assessment may be made regarding security risks which are associated with the VPC, or with deploying a load balancer in the VPC.

[0051] At S240, a check is performed to determine if a node is detected. If ‘no’ execution may continue at S270. In an embodiment, if a match does not exist, a new node may be generated in the security graph to represent the first object. If a match exists execution continues to S250.

[0052] At S250, a check is performed to determine if the matched node corresponds to a previously determined risk factor, or vulnerability. A risk factor, or vulnerability, may be, for example, access to/from a network resource (such as the internet), outdated software, privilege escalation, and the like. A risk factor score may be further determined in some embodiments. The score may indicate the severity of the risk, such as ‘low’, ‘medium’, ‘high’, and ‘critical’. In an embodiment, different instructions may be executed based on the risk factor score. The risk factor may be indicated by metadata associated with the matched node. The metadata may be, for example, data fields which indicate that a risk factor is present. For example, a flag may indicate if a node has external network access. If the matched node corresponds to a previously determined risk factor execution continues at S260, otherwise execution continues at S270. In an embodiment, a vulnerability may be represented on the security graph by a node. As an example, a node corresponding to a workload may be connected to a vulnerability node. Therefore, if the workload node is the matched node, then a security vulnerability may be associated with the code object.

[0053] At optional S260 a notification may be generated to indicate that a security risk has been detected in the configuration code. In an embodiment, the notification may be generated and sent to the client device, user account(s), or both, which authored the code. In some embodiments, the notification may include an indicator to specify why the notification is generated, and what should be performed to mitigate the risk. In the example above, an alert (notification) would be generated if workload includes an outdated software version, and the alert would include the current version, which would need to be configured in the code so as to pass the check.

[0054] At S270 a check is performed to determine if another code object should be inspected. If ‘yes’ execution continues at S220, otherwise execution terminates.

[0055] FIG. 3 is a schematic illustration of a portion of a security graph 300 for risk assessment of instances in a cloud based computing environment, implemented in accordance with an embodiment. The graph 300, which may be stored in a graph database, includes a plurality of nodes. A node may represent a resource, principal, metadata, enrichment data, and the like.

[0056] In this example, the graph includes a first cloud key node 310 and a second cloud key node 320, which are connected to a user account node 340. A third cloud key node 330 is connected to a service account node 360. The user account node 340 and service account node 360 are connected to an identity and access management (IAM) object node 350.

[0057] A cloud key may provide temporary or permanent access between a first workload and a second workload. In some embodiments, one or more first workloads and one or more second workloads may be on the same tenant, on different tenants, or on a combination thereof. Cloud keys may be embedded into text configuration files, structured configuration files (e.g., JSON, YAML, XML, etc.), scripts, source code, and the like. Example implementations of cloud keys include AWS IAM access keys, OAuth refresh tokens, access tokens, and the like.

[0058] By generating a graph including such nodes and populating it with data based on the cloud based computing environment, it is possible to assess security risks. For example, if a first cloud key is compromised, it is readily apparent what other objects are vulnerable as a result. In an embodiment, each node may further store metadata and data relating to the object. For example, a cloud key node 320 may include therein a unique account identifier.

[0059] FIG. 4 is an example of a code object, shown in accordance with an embodiment. A code object 400 includes an object type 410. The object type 410 indicates, in this example, that this code object is a resource type, i.e. executing instructions related to this object will deploy a resource in a cloud computing environment. The object type further includes data fields, such as instance type data field 412 and network association data field 414. The instance type 412 specifies what type of resource is to be deployed, in this case, the instance type is a t2.micro, which is a processing instance used in the AWS cloud computing environment. The network association field 414 indicates, in this example, that the instance should be associated with a specific virtual private cloud (VPC). In this example, the code object is a data structure having parameters (or data fields) which can be customized to generate resources, accounts, and the like, in a cloud computing environment.

[0060] FIG. 5 is an example of a schematic illustration 500 of a unified policy engine across multiple cloud environments, implemented according to an embodiment. A unified policy engine 510 is a policy engine which can be utilized across a full technology stack. A production cycle typically begins in a development environment 540. The development environment may include sandboxed applications, infrastructure as code (IaC) declaratory code (such as configuration code 120 of FIG. 1), and the like. For example, Microsoft® Azure offers Azure DevOps Services which may serve as a cloud based development environment.

[0061] After a workload, policy, or other change in infrastructure is approved from the development environment 540, it is implemented in a staging environment 550. For example, a workload is deployed in the staging environment 550, policy change is updated into a policy engine of the staging environment 550, and the like. A staging environment 550 may be implemented as a cloud computing environment which is identical, or similar, to a production environment in which the workload or change is ultimately deployed. The purpose of a staging environment 550 is to provide a testing environment which simulates the production environment to a high degree. This allows to eventually deploy a workload, for example, with a relatively high certainty that the workload will perform as expected. Where a workload does not perform as expected, it may be returned to the development environment 540, in order to address any problems which were detected during deployment in the staging environment 550.

[0062] A workload which passes testing of the staging environment 550 may be implemented in a production environment 560. The production environment is a cloud computing environment which is in real time use.

[0063] In an example embodiment, a code object may be written as code in a configuration code file, stored in the development environment 540. The configuration code file may then be executed, for example, by Terraform®, to deploy a workload (or user account, as another example) based on the code object in the staging environment 550. The deployed workload may be tested in the staging environment 550, for example, by executing performance tests, load tests, and the like. If the deployed workload passes the tests in the staging environment 550, the code object may be added to a main configuration code file (or committed, per industry term). The next time the main configuration code file is utilized, the code object will be used to deploy instances in the production environment 560.

[0064] Inspectors may be utilized to inspect various objects across different compute environments. For example, a code inspector 520 may inspect for at least an object in each of the development 540 and staging 550 environments. As another example, a graph inspector 530 may inspect for graph objects (i.e., objects which appear in a security graph) in the production environment 560. While this embodiment shows inspector workloads operating in different environments, this is merely for simplicity and pedagogical purposes. In certain embodiments, a first inspector, inspecting for a first object type, may inspect each cloud environment for the first object type. In other embodiments, an inspector for the first object type may be implemented for each compute environment. In some embodiments, an inspector may inspect for an object having a data field, attribute, or other value configured to a predetermined value.

[0065] Typically, system administrators will make changes to a production environment policy in response to detecting a real-world event (as opposed to theoretical test cases done in staging). For example, in response to detecting a vulnerability, a system administrator may update, or create, a policy to address the vulnerability. The policy is stored in a cloud environment of the production environment 560, which is not accessible to the staging environment 550, and typically not readable by the development environment 540. Further, there is no way for an operator of the development environment 540 or staging environment 550 to know about the policy change. Therefore, operators of the development environment 540 and staging environment 550 may continue to create workloads which violate the policies set forth in the production environment 560.

[0066] By utilizing the inspector workloads across all the compute environments, and representing the detected objects in a security graph 505, a unified policy engine 510 may be utilized, which can be used to implement a policy across all the compute environments. In this example, a code object may be detected in the development environment 540. The code object is inspected and the content of the code object (e.g. identifier, type, etc.) may be matched to a node of the security graph 505. The node may be associated with a policy which is accessible to the unified policy engine 510. A check may be performed to determine if an instance generated based on the detected code object would comply with the associated policy. Thus, a code object can be failed at the development environment 540 based on a policy of the production environment 560, without wasting resources and time of going through staging, for example.

[0067] FIG. 6 is an example of a flowchart 600 for generating an inspection instruction based on a detected code object, implemented in accordance with an embodiment.

[0068] At S610 a code object is extracted from a configuration code file. The configuration code file includes a plurality of code objects, at least a portion of which include instructions that, when executed by an orchestrator, cause generation of principals or resources in a cloud computing environment.

[0069] At S620 a security graph is traversed to detect a node which is associated with the code object. A node is associated with a code object if, for example, a data field of the node and a data field of the code object match. In the example presented in FIG. 5 above the code object may be matched to a node which represents a VPC. A code object may also match a node, if for example, a workload generated based on the code object is represented by the node.

[0070] At S630 a check is performed to determine if the detected node should be inspected. If ‘yes’ execution continues at S640. If ‘no’ execution may terminate, or in another embodiments continue at S620 with another node. In yet another embodiment if the check returns ‘no’ execution may continue at S610 with another code object.

[0071] At S640 an instruction to initiate an inspection of a workload corresponding to the node is generated. Inspecting the workload may include generating a snapshot of a disk of the workload, and providing access to the snapshot through an inspection service account to an inspector (such as inspector 160 of FIG. 1). In an embodiment a volume may be mounted based on the snapshot, which the inspector 160 may access to inspect for at least a data object.

[0072] Generating inspection instructions based on code objects is advantageous as it reduces the requirement to inspect a network environment for virtual workloads. Instead, new workloads may be discovered by inspecting the code which generates them, while security issues in workloads in a production environment may in turn be traced back to code objects from which they are generated.

[0073] FIG. 7 is an example of a schematic of a software container cluster having an admission controller for policy implementation, utilized to describe an embodiment. In an embodiment, a container cluster 710 is deployed on a computer system, such as described in more detail in FIG. 10 below.

[0074] In some embodiments, a software container cluster 710 is implemented utilizing a Kubernetes® platform, a Docker® Engine, and the like. In certain embodiments, a software container cluster 710 is configured to deploy a plurality of software containers. In an embodiment, a software container is a containerized software application.

[0075] In certain embodiments, a container cluster 710 includes a control plane 720 configured to communicate with an inspection application programming interface (API) 740, and a plurality of nodes 730-1 through 730-N, where ‘N’ is an integer having a value of ‘2’ or greater, individually referred to as node 730 and collectively referred to as nodes 730.

[0076] In an embodiment, the control plane 720 is implemented on a single machine in the cluster. In some embodiments, the machine on which the control plane 720 is implemented only executes components of the control plane 720. For example, in an embodiment, the machine does not include a container based on a user-generated image, base image, and the like.

[0077] For example, in some embodiments, a Kubernetes container cluster control plane 720 includes components such as an API server, a key value store, a scheduler, a controller, and the like. In an embodiment, the API server is implemented as a kube-apiserver, which is configured to expose the Kubernetes API to external resources. In certain embodiments, the key value store is configured to store key values, cluster data, and the like.

[0078] In some embodiments, the controller includes a node controller, a job controller, a service account controller, and the like. In certain embodiments, the control plane 720 includes a webhook 724. In an embodiment, the webhook 724 is a validating webhook, a mutating webhook, and the like. In an embodiment, a webhook 724 is configured to detect a request to an API, to another node in the cluster, and the like. In certain embodiments, the webhook 724 is further configured to send the request to an admission controller 722.

[0079] In an embodiment, the cluster 710 includes a plurality of nodes 730-1 through 730-N. In certain embodiments, each node 730 includes a container 732. In some embodiments, the container 732 includes a containerized software application. In certain embodiments, a node 730 includes a plurality of containers, an agent, a network proxy, a combination thereof, and the like. In an embodiment, a containerized software application includes software, dependencies of the software, a combination thereof, and the like.

[0080] In certain embodiments, an inspection API 740 is configured to expose resources, communication, and the like, with a cloud computing environment. For example, in an embodiment, a cloud computing environment is a virtual private cloud (VPC), a virtual network (VNet), and the like, deployed on a cloud computing infrastructure. In an embodiment, a cloud computing infrastructure is Amazon® Web Services (AWS), Google® Cloud Platform (GCP), Microsoft® Azure, and the like. In certain embodiments, the control plane 720 of the cluster 710 is configured to communicate through the inspection API 740.

[0081] In some embodiments, an admission controller 722 is deployed on a node 730-1. In an embodiment, an admission controller 722 is configured to receive intercepted requests to the API server of the control plane 720. For example, in an embodiment, a software container 732-N is configured to communicate through a node 730-N to an API server of the control plane 720, which in turn is configured to communicate with the inspection API 740.

[0082] In certain embodiments, the admission controller 722 is implemented as computer software deployed on a node of the cluster 710. In some embodiments, the admission controller 722 is configured to communicate with a unified policy engine 810, for example, through the inspection API 740.

[0083] In some embodiments, the admission controller 722 is configured to request a policy from the unified policy engine 710. In an embodiment, the admission controller 722 is configured to apply the received policy on a request intercepted from a container 732-1 of a node 730-1.

[0084] In some embodiments, a policy includes a conditional rule. For example, in an embodiment, a policy includes a conditional rule, utilized to check if a network communication is directed to an IP address which is on a list of banned IP addresses. In an embodiment, a request is generated by a software container 732-N to send a network message, the request including a destination address (e.g., an IP address). In an embodiment, the request is delivered from the node 730-N to the control plane 720, where the request is intercepted by the webhook 724. The request is sent to the admission controller 722, which is configured to apply a policy on the request.

[0085] In some embodiments, the admission controller 722 is configured to apply a policy to the request. For example, in an embodiment, the admission controller 722 is configured to apply a conditional rule such that if a communication is directed to an IP address stored in a list of blocked IP addresses, the communication is denied, and the request is not passed to the inspection API 740. In certain embodiments, the admission controller 722 is configured to apply a conditional rule such that if a communication is not directed to an IP address stored in a list of blocked IP addresses, the communication is allowed to pass through, and is forwarded, for example, to the inspection API 740.

[0086] In an embodiment, the admission controller 722 is configured to apply a conditional rule such that if a communication is directed to an IP address stored in a list of allowed IP addresses, the communication is allowed, and the request is passed to the inspection API 740. In some embodiments, the admission controller 722 is configured to apply a conditional rule such that if a communication is not directed to an IP address stored in a list of allowed IP addresses, the communication is denied, and the request is not passed to the inspection API 740.

[0087] FIG. 8 is an example of a network diagram with multiple computing environments utilizing a unified policy engine, implemented according to an embodiment. In an embodiment, a unified policy engine 810 includes a rule, a policy, a combination thereof, and the like. In some embodiments, a rule includes a condition, for example, such that when the condition is met an action is performed, when the condition is met an action is refrained from being performed, when a condition is not met an action is performed, when a condition is not met an action is refrained from being performed, combinations thereof, and the like.

[0088] In some embodiments, a unified policy engine 810 supplies rules, policies, and the like, to various computing environments. For example, in an embodiment, the unified policy engine supplies a rule to a first cloud computing environment 820, a second cloud computing environment 830, and an infrastructure as code (IaC) environment 840.

[0089] In an embodiment, a cloud computing environment is a virtual private cloud (VPC), a virtual network (VNET), and the like, implemented on a cloud computing infrastructure. According to an embodiment, a cloud computing infrastructure is, for example, Amazon® Web Services (AWS), Microsoft® Azure, Google® Cloud Platform (GCP), and the like.

[0090] In certain embodiments, an IaC environment 840 is utilized, for example, with Terraform®, Ansible®, Chef®, Puppet®, and the like.

[0091] In certain embodiments, security policies are maintained for different compute environments, for example, in order to secure certain digital assets, prevent unwanted or unintended access, and the like. In some embodiments, for example, where continuous integration and continuous deployment (CI/CD) is implemented, multiple compute environments are related. For example, according to an embodiment, declaratory code in an IaC environment 840 is utilized to deploy a software container cluster 822 in a staging environment 820.

[0092] In an embodiment, a staging environment is a cloud computing environment in which resources, principals, and the like, are deployed prior to being deployed in a production environment, such as production environment 830. This is beneficial as it allows to test and benchmark a resource, such as the container cluster 822 prior to deploying a counterpart to the container cluster 822 in the production environment 830. For example, in an embodiment, the counterpart to the container cluster 822 deployed in the staging environment 820 is the software container cluster 832 deployed in the production environment 830. In an embodiment, the production environment 830 includes different types of resources, virtualizations, and the like, such as a virtual machine 834, a serverless function 836, a combination thereof (i.e., a nested virtualization), and the like.

[0093] According to an embodiment, once a resource, such as the container cluster 822 passes a benchmark, test, and the like, code utilized to deploy the container cluster 822 in the staging environment 820 can be utilized to deploy the container luster 832 in the production environment 830. In some embodiments, it is beneficial to take action based on a code object, a resource deployed in a staging environment based on the code object, and a corresponding resource deployed in the production environment, wherein the action applies to each of the code object and two resources.

[0094] For example, in some embodiments, it is useful to employ a policy on a code object, on a resource deployed in a staging environment 820, and a corresponding resource deployed in a production environment 830, as all these correspond to each other. In certain embodiments, a policy is enacted based on observation of a resource, such as the container cluster 822, in a staging environment.

[0095] Utilizing a unified policy engine 810 allows to store a single policy utilized by each related computing environment. This is preferable to storing a corresponding policy in each computing environment, especially when these computing environments are related to each other. In an embodiment, utilizing a single unified policy engine 810 also reduces storage space required to store redundant similar policies, as it eliminates the need to store a corresponding policy in each different (yet related) computing environment.

[0096] Furthermore, configuring a software container cluster to deploy an admission controller which is configured to utilize policies from the unified policy engine 810 provides a level of assurance that a policy is enacted on each container in the cluster, and across multiple clusters in any computing environment. A single policy is therefore applied equally, objectively, and consistently. While it is recognized, for example, that a human can apply a condition to a resource, it is also recognized that a human is incapable of applying a condition (e.g., a policy) in a manner that is equal and objective in a consistent manner across multiple computing environments, and can certainly not do so within a timeframe that would make application of such a policy useful.

[0097] FIG. 9 is an example flowchart of a method for deploying a policy-enforcing admission controller for a software container, implemented in accordance with an embodiment.

[0098] At S910, an admission controller is deployed. In some embodiments, a plurality of admission controllers are deployed. In an embodiment, the admission controller is deployed in a control plane of a software container cluster. In some embodiments, a software container cluster is implemented on a Kubernetes® platform.

[0099] In certain embodiments, the admission controller is configured to intercept API requests between a node in the container cluster and an inspection API of the container cluster. In an embodiment, the admission controller is configured as a mutating admission controller, a validating admission controller, a combination thereof, and the like. In certain embodiments, a plurality of admission controllers, including a mutating admission controller and a validating admission controller, are deployed.

[0100] In some embodiments, a mutating admission controller is configured to modify a request which is received by the admission controller. For example, in an embodiment, the admission controller is configured to modify a request based on a policy received from a unified policy engine.

[0101] In certain embodiments, a validating admission controller is configured to validate a request without changing the request itself. In certain embodiments, an admission controller is configured to validate a request which was modified by a mutating admission controller.

[0102] At S920, a check is performed for a policy. In an embodiment, an admission controller is configured to periodically check, for example, by sending a request to a unified policy engine, to receive a new policy. In certain embodiments, the admission controller is configured to send to the unified policy engine a policy version number. In some embodiments, the unified policy engine is configured to compare a received policy version to a stored policy version, and send an admission controller the stored policy version in response to determining that the received version is older than the stored version.

[0103] At S930, the policy is applied. In an embodiment, the admission controller is configured to apply the policy, for example, on a container deployed in a node of the cluster where the admission controller is deployed. In certain embodiments, a plurality of policies are applied.

[0104] In some embodiments, an admission controller is configured to merge a plurality of policies, such as a first policy and a second policy, into a single policy, and apply the single policy to each container, pod, and the like, in the cluster. In certain embodiments, a policy is merged by extracting a conditional rule from a first policy, extracting a conditional rule from a second policy, and generating a new conditional rule, for example, by adding a Boolean “AND” operator between the conditional rule of the first policy and the conditional rule of the second policy.

[0105] In some embodiments, a policy is applied to each occurrence where a node, a pod, a container, and the like, access the control plane of the cluster. For example, in an embodiment, a policy is applied in response to detecting an instruction to deploy a node, a pod, a container, a combination thereof, and the like, in the cluster. In some embodiments, a policy is applied on a request originating from a node, a pod, a container, a combination thereof, and the like, such as a request to communicate with an IP address through an inspection API.

[0106] FIG. 10 is a flowchart of a method for generating a contextual policy in a computing environment, implemented in accordance with an embodiment. In certain embodiments, a contextual policy is generated based on an existing policy, based on an exception to an existing policy, based on a detected cybersecurity object in a computing environment, combinations thereof, and the like.

[0107] In an embodiment, a contextual policy is a policy which is generated based on a context detected in a computing environment. For example, in some embodiments, a policy includes a condition that a cybersecurity object of a first type, such as a cleartext password, should not be stored on a deployed resource.

[0108] In an embodiment, a context is generated for a detected cybersecurity object. For example, in some embodiments, a first cleartext password provides a limited set of permissions in a cloud computing environment, while a second cleartext password provides administrator privilege in the cloud computing environment. In some embodiments, context is generated based on a security graph which stores therein a representation of a computing environment. For example, according to an embodiment, a node in the security graph represents a resource, a principal, a context, an enrichment, an endpoint, a combination thereof, and the like.

[0109] By determining the context of each cleartext password, according to an embodiment, it is possible to permit some workloads to deploy (e.g., workloads which contain a cleartext password with limited permissions) while denying deployment of other workloads (e.g., workloads which contain a cleartext password with administrator privileges).

[0110] In an embodiment, a security graph is generated by performing network discovery of a computing environment, and inspecting, scanning, and the like, each discovered resource in the computing environment for cybersecurity objects. In some embodiments, each discovered resource, cybersecurity object, and the like, is represented as a node in the security graph. In certain embodiments, principals are detected in the computing environment, such as a user account, a service account, a role, and the like. In some embodiments, an identity and access management service is accessed to determine a permission associated with a principal.

[0111] In some embodiments, a principal is a cloud entity which includes a permission, authorization, and the like, to act on a resource, initiate an action in the computing environment, a combination thereof, and the like.

[0112] In certain embodiments, a resource is a virtual machine, a software container, a serverless function, an application, a software as a service, an infrastructure as code platform, a provisioned hardware resource, a storage, a bucket in a cloud computing environment, a combination thereof, and the like.

[0113] At S1010, a cybersecurity object is detected. In an embodiment, the cybersecurity object is detected on a deployed virtualization. A deployed virtualization is, according to an embodiment, a virtual machine, a software container, a serverless function, a combination thereof, and the like.

[0114] In some embodiments, a cybersecurity object is an operating system, a software application, a cleartext password, a plaintext password, an encryption key, a certificate, a misconfiguration, a vulnerability, an exposure, a combination thereof, and the like.

[0115] In an embodiment, the cybersecurity object is detected utilizing a scanner, an inspector, and the like. In certain embodiments, a representation of the cybersecurity object is stored on a security graph. In an embodiment, the security graph includes a representation of a computing environment, for example, by generating nodes which represent resources, principals, enrichments, and the like, detected in the computing environment.

[0116] In some embodiments, detection of resources, principals, and the like, is performed by utilizing network discovery. In an embodiment, a node representing a cybersecurity object is connected to a node representing a cloud entity (e.g., a resource, a principal, and the like). In some embodiments, the security graph is traversed to detect a node representing a resource, based on the cybersecurity object. For example, an identifier of the cybersecurity object is utilized to generate a query for the security graph.

[0117] At S1020, a policy is detected. In an embodiment, the policy is applied to the computing environment in which the cybersecurity object is detected. In some embodiments, the policy is detected by extracting an identifier of the cybersecurity object, and matching the identifier to a policy. In an embodiment, matching the identifier to a policy is performed by querying an identity and access management service.

[0118] In some embodiments, a policy is detected based on an identifier of a resource on which the cybersecurity object is detected. For example, in an embodiment, data pertaining to the resource, metadata of the resource, and the like, are utilized to detect a policy. For example, in an embodiment, an identifier of a resource is utilized to detect a policy. In certain embodiments, a policy engine is queried with the identifier to detect a policy.

[0119] At S1030, a contextual policy is generated. In an embodiment, a contextual policy is generated based on an applied policy and the cybersecurity object. In certain embodiments, a contextual policy is generated based on the applied policy and an exception generated based on the cybersecurity object. In some embodiments, the applied policy includes a rule, such that the contextual policy includes the rule which is applied other than in instances where the exception is true (e.g., a condition of the exception is true).

[0120] In certain embodiments, the exception is exclusionary, while in other embodiments, the exception is inclusionary. According to an embodiment, an exception is exclusionary where the applied policy is applied to all instances, other than instances where a condition of the exception is true.

[0121] In some embodiments, the exception is inclusionary, such that the exception is applied to some instances, and applied to another instance to which the applied policy would not apply if not for the exception condition.

[0122] For example, in an embodiment, a rule includes a condition that no container can be deployed with a cleartext password (a cybersecurity object). In an embodiment, a first cleartext password provides administrator privileges, while a second cleartext password provides limited privileges. Therefore, a contextual policy is generated based on the rule (e.g., no container deployed with a cleartext password) and an exception (e.g., cleartext passwords with limited privilege).

[0123] In an embodiment, the second cleartext password is detected on a deployed workload. In some embodiments, a security graph, identity and access management service, and the like, are queried to determine a permission associated with the second cleartext password. In an embodiment, where the second cleartext password is associated with limited permissions (i.e., not administrator permissions), an exception is generated to the policy rule which states that no container can be deployed with a cleartext password.

[0124] At S1040, an admission controller is configured to apply the contextual policy. In an embodiment, the admission controller is configured to periodically request policies, rules, exceptions, and the like. In some embodiments, the admission controller applies the contextual rule prior to deploying a software container in the software container cluster. In certain embodiments, the admission controller is configured to apply the contextual rule to each request sent to a software container in the software container cluster. In an embodiment, the admission controller is configured to apply the contextual tool to each communication directed to a software container in the software container cluster.

[0125] In some embodiments, the contextual policy is generated by a unified policy engine and sent from the unified policy engine to each of a plurality of admission controllers, each admission controller deployed in a software container cluster of a plurality of software container clusters. In certain embodiments, each software container cluster of the plurality of software container clusters is deployed in a different cloud computing environment. In an embodiment, each cloud computing environment is deployed on a different cloud computing infrastructure.

[0126] For example, according to an embodiment a first software container cluster is deployed in a first cloud computing environment (e.g., a virtual private cloud-VPC), the first cloud computing environment deployed on Amazon® Web Services (AWS), and a second software container cluster is deployed in a second cloud computing environment (e.g., a virtual network-VNet), the second cloud computing environment deployed on Microsoft® Azure.

[0127] FIG. 11 is an example flowchart 1100 of a method for service discovery in a computing environment, implemented in accordance with an embodiment.

[0128] At S1110, a code object is detected. In an embodiment, a code object is detected in a computing environment. In some embodiments, a code object includes a secret (such as a public key, a private key, etc.), resource type, a policy identifier, a role identifier, a status of a flag, a combination thereof, and the like.

[0129] In certain embodiments, a computing environment is a cloud computing environment. In an embodiment, a cloud computing environment is a virtual private cloud (VPC), a virtual network (VNET), and the like, implemented on a cloud computing infrastructure.

[0130] According to an embodiment, a cloud computing infrastructure is, for example, Amazon® Web Services (AWS), Microsoft® Azure, Google® Cloud Platform (GCP), and the like. In an embodiment, the code object is a portion of declaratory code.

[0131] In some embodiments, the declaratory code is in a declaratory computer language, which an orchestrator (e.g., as in FIG. 1) is configured to deploy instances in the cloud environment based on the declarations in the declaratory code.

[0132] According to an embodiment, a code object is detected utilizing static analysis techniques, by accessing a code repository, accessing a file including computer code, accessing a command line interface (CLI), a combination thereof, and the like.

[0133] At S1120, a resource is detected. In some embodiments, the resource is deployed based on the code object. In an embodiment, a resource is deployed in the computing environment based on a detected code object. In an example embodiment, a code object includes an object type (FIG. 4, 410) which indicates that this code object is a resource type, i.e., executing instructions related to this code object will result in deploying a resource in a cloud computing environment.

[0134] In this example embodiment, the code object is a data structure having parameters (e.g., data fields) which are customized with data values to generate entities such as resources, accounts, and the like, in a cloud computing environment.

[0135] In an embodiment, a resource is detected utilizing a network discovery technique. For example, in some embodiments, discovering a resource in a network, for example, of a computing environment, includes determining an IP range utilized by resources in the network and sending a PING, SYN, etc., instruction, which is used to determine presence of a resource based on a response.

[0136] In some embodiments, a resource is detected in a computing environment, such as a cloud computing environment, by querying an API of the computing environment to discover what resources are deployed therein.

[0137] At S1130, a representation of the code object is generated. In an embodiment, a representation of the code object is generated in a security database. In an embodiment, a security database further includes a representation of the computing environment.

[0138] In an embodiment, the representation is generated based on a unified data schema, which includes a predefined template, data structure, and the like, which is utilized to represent the code object. For example, in some embodiments, the security database is implemented as a graph database, such as Neo4j®, and is stored based on a graph schema, including different nodes, edges, etc.

[0139] At S1140, a representation of the resource is generated. In certain embodiments, a representation of the resource is generated in the security database. In an embodiment, the representation of the resource is connected to the representation of the code object.

[0140] In some embodiments, the representation of the code object is connected to a plurality of nodes, each node representing a resource which is deployed based on the same code object.

[0141] For example, in an embodiment, a plurality of nodes of a software container are deployed based on a single image, such that the single image is the code object, and the plurality of nodes are each a resource of a plurality of resources. In such an embodiment, the single image is represented by a node in a security graph, and the node is connected to a plurality of nodes, each node of the plurality of nodes representing a node of software container.

[0142] At 1150, a representation of a service is generated. In an embodiment, the representation of a service is generated in a security base. In some embodiments, the representation of the service is connected to the representation of the code object and the representation of the resource.

[0143] In an embodiment, the representation of the service is connected in the security database to a representation of a dependent component (e.g., a resource such as a database, a messaging queue, and the like), a representation of a software artifact, a representation of a repository, a representation of a deployed instance, a representation of a code object, various combinations thereof, and the like.

[0144] In an embodiment, a representation of a service is connected to a representation of a service instance. In some embodiments, a service is utilized in multiple computing environments, for example, a Kubernetes cluster which is deployed in both a staging environment and a production environment. In such an embodiment, a service is represented in the security database, which is connected to a first representation of a service instance (e.g., the cluster deployed in the staging environment) and connected to a second representation of the service instance (e.g., the cluster deployed in the production environment).

[0145] At 1160, the code object is inspected. In an example, the code object is inspected for a first cybersecurity object. In some embodiments, the cybersecurity object is an identity object, a file, a folder, a filesystem, a software application, a software library, a software binary, a cryptographic key, a certificate, a password, a code object, a software call, a malware object, a combination thereof, and the like.

[0146] In certain embodiments, an inspector, such as discussed in more detail in FIG. 1 above, is configured to inspect a code object, for example, by reading a code file and parsing the code into data fields, extracting values of the data fields, and comparing the extracted values to preexisting values, value types, etc.

[0147] At 1170, the resource is inspected. For example, the resource is inspected for a second cybersecurity object. In an embodiment, inspecting a resource includes utilizing static analysis techniques. According to certain embodiments, inspecting a resource includes detecting a disk associated with the resource, such as a disk provisioned, assigned, etc., to the resource.

[0148] In an embodiment, an inspectable disk is generated based on the detected disk of the resource. In some embodiments, the inspectable disk is generated based on a clone, a snapshot, a copy, and the like, of the original disk. In certain embodiments, it is advantageous to generate a cloned disk as the inspectable disk, as the clone is available instantaneously, while a snapshot for example, requires that the entire snapshot data is written prior to the snapshot being accessible for inspection.

[0149] At 1180, a context is generated. In an embodiment, the context is generated for the representation of the service. In certain embodiments, a context for the representation of the service is generated based on a first result of inspecting the code object and a second result of inspecting the resource. In an embodiment, a context includes a build time, a code commit, a security testing result, an enforced policy, a policy exception, a list of service instance identifiers, an identifier version per service instance, a combination thereof, and the like.

[0150] In an embodiment, context includes a service owner, a risk level associated with the software service, a risk level associated with a component of the service, additional properties (e.g., SLA on bug fixes), security contact for the service, source of code for the service, etc.

[0151] In certain embodiments, the context further includes principal information, such as principals that access the service, principals that act on the service, principals that are utilized by the service, principals which are utilized by components of the service, a combination thereof, and the like.

[0152] As an example, a software container image is associated with a code object from which the software container is deployed. In some embodiments, a software image includes a plurality of binaries (i.e., software binaries), which are detected via inspection of the software image. According to various embodiments, a source of the software image, a source of a software binary, a combination thereof, and the like, is determined.

[0153] FIG. 12 is an example flowchart 1200 of a method for cybersecurity policy enforcement on a service in a computing environment, according to an embodiment. In an embodiment, a policy is enforced on a service, on a service instance, on a plurality of service instances, on a combination thereof, and the like.

[0154] At S1210, a software service is detected. In an embodiment, a software service is detected in a computing environment. In certain embodiments, the software service includes a code object and a resource. In some embodiments, the software service is detected based on the methods described in more detail herein.

[0155] In an embodiment, a computing environment includes a cloud computing environment, a registry, a repository, a CI/CD environment, a CLI environment, various combinations thereof, and the like. In certain embodiments, each component of the computing environment is inspected, for example, utilizing static analysis, runtime data (e.g., utilizing a sensor deployed on a workload), a combination thereof, and the like, to detect cybersecurity objects.

[0156] In some embodiments, a service is detected based on detection of a code object which is utilized to deploy a plurality of resources, software artifacts, forensic artifacts, events in a cloud log, a combination thereof, and the like.

[0157] At S1220, a representation of the software service is generated. In some embodiments, a representation of the software service is generated in a security database. In certain embodiments, the security database further includes a representation of the computing environment.

[0158] In an embodiment, the representation of the software service is connected to a representation of an instance of software service. For example, according to certain embodiments, a plurality of instances of the software service are deployed across different computing environments, such as a production environment, a staging environment, a testing environment, etc.

[0159] At S1230, a policy is applied to the representation of the software service. In some embodiments, the policy includes a conditional rule. In an embodiment, applying a policy on a representation of the software service includes providing the policy, the conditional rule, the representation of the software service, and the like, to a policy engine. In an embodiment, the policy engine is configured to apply the rule, for example, by determining if the conditional rule is satisfied (e.g., is ‘true’).

[0160] For example, according to an embodiment, a conditional rule checks that a database application is password protected. In an embodiment, the representation of the database, which is a component of the software service, is connected to a representation of the service. In certain embodiments, the policy is applied to the representation of the database, which does not include a password. Therefore, the conditional rule, when applied to the representation of the database, results in a fail (or ‘false) result.

[0161] At S1240, a remediation action is initiated in response to detecting a policy fail. In some embodiments, a remediation action is initiated. In an embodiment, the remediation action is initiated in response to detecting a policy fail when applying the policy on the representation of the software service.

[0162] According to an embodiment, the remediation action includes initiating a remediation action on each component of the software service, on a portion of components of the software service, on single component of the software service, and the like.

[0163] In an embodiment, the remediation action is initiated only on a component which caused the software service to fail the policy. In certain embodiments, the remediation action includes updating a software, installing a software patch, revoking access to a resource, revoking access from a resource, revoking access to a principal, revoking access from a principal, generating an alert, updating a severity of an alert, generating a support ticket, updating a severity of a ticket, a combination thereof, and the like.

[0164] In some embodiments, the remediation action is initiated on each instance of the software service. According to some embodiments, the remediation action is initiated on each instance of the software service which corresponds to a specific version number. In some embodiments, a first remediation action is initiated in a first computing environment, and a second remediation action is initiated in a second computing environment.

[0165] FIG. 13 is an example flowchart 1300 of a method for managing a cybersecurity policy exception on a software service in a computing environment, according to an embodiment.

[0166] At S1310, a software service is detected. In some embodiments, a software service is detected in a computing environment. In some embodiments, the software service includes a code object and a resource. In an embodiment, a software service is detected in a computing environment. In certain embodiments, the software service includes a code object and a resource. In some embodiments, the software service is detected based on the methods described in more detail herein.

[0167] In an embodiment, a computing environment includes a cloud computing environment, a registry, a repository, a CI/CD environment, a CLI environment, various combinations thereof, and the like. In certain embodiments, each component of the computing environment is inspected, for example, utilizing static analysis, runtime data (e.g., utilizing a sensor deployed on a workload), a combination thereof, and the like, to detect cybersecurity objects.

[0168] In some embodiments, a service is detected based on detection of a code object which is utilized to deploy a plurality of resources, software artifacts, forensic artifacts, events in a cloud log, a combination thereof, and the like.

[0169] At S1320, a representation of the software service is generated. In some embodiments, the representation of a software service is generated in a security database. In an embodiment, the security database includes a representation of the computing environment.

[0170] In an embodiment, the representation of the software service is connected to a representation of an instance of software service. For example, according to certain embodiments, a plurality of instances of the software service are deployed across different computing environments, such as a production environment, a staging environment, a testing environment, etc.

[0171] At S1330, a policy is applied on the representation of the software service. In some embodiments, a policy includes a conditional rule. In an embodiment, applying a policy on a representation of the software service includes providing the policy, the conditional rule, the representation of the software service, and the like, to a policy engine. In an embodiment, the policy engine is configured to apply the rule, for example, by determining if the conditional rule is satisfied (e.g., is ‘true’).

[0172] For example, according to an embodiment, a conditional rule checks that a database application is password protected. In an embodiment, the representation of the database, which is a component of the software service, is connected to a representation of the service. In certain embodiments, the policy is applied to the representation of the database, which does not include a password. Therefore, the conditional rule, when applied to the representation of the database, results in a fail (or ‘false) result.

[0173] At S1340, a policy exception is detected. In some embodiments, a policy exception is detected in response to applying the policy resulting in a policy fail of the conditional rule.

[0174] In an embodiment, a policy exception is based on an identifier of a resource, an identifier of a software service, an identifier of an instance of the software service, an identifier of the computing environment in which the resource, the software service, and the like is deployed, various combinations thereof, and the like.

[0175] At S1350, it is determined that the software service passes the policy. In certain embodiments, it is determined that the software service passes the policy in response to applying the policy exception resulting in a pass. In an embodiment, applying an exception to the policy is applied across all software service instances, and for each component thereof.

[0176] According to an embodiment, applying a policy exception in this manner allows to generate a single exception which is applied to each software service instance, each component thereof, and each computing environment in which the software service is deployed. This is advantageous, in an embodiment, as it reduces the amount of policies utilized for a computing environment, and further eliminates the possibility of an exception mismatch, such that an exception would be applied with one policy, but not with another corresponding policy, where multiple policies would otherwise be utilized.

[0177] At S1360, a remediation action is initiated. In some embodiments, a remediation action is generated in response to determining that applying the policy exception results in a policy fail.

[0178] According to an embodiment, the remediation action includes initiating a remediation action on each component of the software service, on a portion of components of the software service, on single component of the software service, and the like.

[0179] In an embodiment, the remediation action is initiated only on a component which caused the software service to fail the policy. In certain embodiments, the remediation action includes updating a software, installing a software patch, revoking access to a resource, revoking access from a resource, revoking access to a principal, revoking access from a principal, generating an alert, updating a severity of an alert, generating a support ticket, updating a severity of a ticket, a combination thereof, and the like.

[0180] In some embodiments, the remediation action is initiated on each instance of the software service. According to some embodiments, the remediation action is initiated on each instance of the software service which corresponds to a specific version number. In some embodiments, a first remediation action is initiated in a first computing environment, and a second remediation action is initiated in a second computing environment.

[0181] FIG. 14 is an example flowchart 1400 of a method for initiating a remediation action on a software service in a computing environment, according to an embodiment.

[0182] At S1410, a software service is detected. In some embodiments, a software service is detected in a computing environment. In certain embodiments, the software service includes a code object and a resource. In an embodiment, a software service is detected in a computing environment. In certain embodiments, the software service includes a code object and a resource. In some embodiments, the software service is detected based on the methods described in more detail herein.

[0183] In an embodiment, a computing environment includes a cloud computing environment, a registry, a repository, a CI/CD environment, a CLI environment, various combinations thereof, and the like. In certain embodiments, each component of the computing environment is inspected, for example, utilizing static analysis, runtime data (e.g., utilizing a sensor deployed on a workload), a combination thereof, and the like, to detect cybersecurity objects.

[0184] In some embodiments, a service is detected based on detection of a code object which is utilized to deploy a plurality of resources, software artifacts, forensic artifacts, events in a cloud log, a combination thereof, and the like.

[0185] At S1420, a representation of the software service is generated. In some embodiments, a representation of the software service is generated in a security database. In certain embodiments, the security database further includes a representation of the computing environment.

[0186] In an embodiment, the representation of the software service is connected to a representation of an instance of software service. For example, according to certain embodiments, a plurality of instances of the software service are deployed across different computing environments, such as a production environment, a staging environment, a testing environment, etc.

[0187] At S1430, a plurality of components is detected. In an embodiment, a security database is traversed, queried, and the like, to detect the plurality of components. In some embodiments, each component of a plurality of components have a representation connected to the representation of the software service.

[0188] In an embodiment, a first group of components of the plurality of components are associated with a first instance of the software service, and a second group of components of the plurality of components are associated with a second instance of the software service.

[0189] At S1440, inspection is initiated for a cybersecurity object on each component. In some embodiments, inspection is initiated on each component of the software service for detecting a cybersecurity object.

[0190] In an embodiment, inspecting a component of a software service includes generating a clone, a copy, a snapshot, and the like. In some embodiments, an inspectable disk is generated for inspection, which is inspected instead of the original disk, allowing the original disk to remain unperturbed. This is particularly advantageous, in an embodiment, in a production environment.

[0191] In some embodiments, inspecting a resource includes utilizing static analysis techniques. According to certain embodiments, inspecting a resource includes detecting a disk associated with the resource, such as a disk provisioned, assigned, etc., to the resource.

[0192] In an embodiment, an inspectable disk is generated based on the detected disk of the resource. In some embodiments, the inspectable disk is generated based on a clone, a snapshot, a copy, and the like, of the original disk. In certain embodiments, it is advantageous to generate a cloned disk as the inspectable disk, as the clone is available instantaneously, while a snapshot for example, requires that the entire snapshot data is written prior to the snapshot being accessible for inspection.

[0193] At S1450, a remediation action is initiated. In an embodiment, the remediation action is initiated on each component of a software service. In some embodiments, a remediation action is initiated on each component of the software service on which the cybersecurity object is detected.

[0194] In an embodiment, the remediation action is initiated only on a component which caused the software service to fail the policy. In certain embodiments, the remediation action includes updating a software, installing a software patch, revoking access to a resource, revoking access from a resource, revoking access to a principal, revoking access from a principal, generating an alert, updating a severity of an alert, generating a support ticket, updating a severity of a ticket, a combination thereof, and the like.

[0195] In some embodiments, the remediation action is initiated on each instance of the software service. According to some embodiments, the remediation action is initiated on each instance of the software service which corresponds to a specific version number. In some embodiments, a first remediation action is initiated in a first computing environment, and a second remediation action is initiated in a second computing environment.

[0196] FIG. 15 is an example flowchart 1500 of a method for automatic implementation of runtime cybersecurity rules, according to an embodiment.

[0197] According to an embodiment, a service catalog of software services is generated. In an embodiments, a service catalog includes detected binaries which are executed in a computing environment, such as a cloud computing environment. For example, according to an embodiment, code objects, binaries, etc., are detected by performing inspection, static analysis, and the like, on disks deployed in the computing environment. In an embodiment, binaries, code objects, etc., are detected in a repository, such as of a version control system.

[0198] In an embodiment, static analysis is performed on binaries, code objects, and the like, to determine which such objects are related. Objects are related where, for example, they share substantial amounts of code, share substantial functionalities, and the like. Results of static analysis may be stored in a security database, for example, by representing objects using nodes and relationships (e.g., “are related”).

[0199] In certain embodiments, related applications, binaries, and the like are represented by a service. For example, a software service includes multiple resources, applications, and the like, which together form the software service. In an embodiment, the software service representation includes a representation of different versions of the software service, a representation of software container clusters, a representation of workloads, and the like.

[0200] At S1510, a code object is detected. In certain embodiments, a code object of a cloud computing environment is detected. In some embodiments, the code object is detected in any one of: a continuous integration and continuous delivery (CI/CD) environment, a command-line interface (CLI) environment, an infrastructure as code (IaC) environment, a code repository, a version control system (VCS), a combination thereof, and the like. In another embodiment, a representation in a security database for each of the code object and/or a resource is generated.

[0201] In an embodiment, detecting a code object includes detecting an identifier of a code object, a code object type, metadata related to the code object, a combination thereof, and the like.

[0202] At S1520, static analysis is initiated on the code object. In some embodiments static analysis includes analyzing the source code without having to execute the full program. In an embodiment, static analysis refers to the operation performed by a source code analysis tool, which is the analysis of a set of code against a set or multiple sets of coding rules. In an embodiment, the code object is analyzed to detect any one of: a role, a software application, a software function, a domain, a process, a file, a call stack, and any combination thereof.

[0203] At S1530, a resource is deployed. In an embodiment, the code object is utilized to deploy a resource in the cloud computing environment. In some embodiments, a plurality of resources are deployed based on a single code object. For example, in an embodiment, multiple web servers are deployed behind a load balancer, each web server deployed based on a code object.

[0204] In some embodiments, the resource is a workload, a virtual instance, and the like. In an embodiment, the resource is a virtual machine which is part of an auto-scaling group (ASG) which includes a plurality of virtual machines which are all deployed based on the same code object.

[0205] At S1540, a behavior baseline of a resource is generated. In some embodiments, a behavior baseline of a resource is based on a result of the static analysis of the code object is generated.

[0206] For example, in an embodiment, a code object is analyzed and a call to a storage, such as a bucket, is detected in the code object. According to an embodiment, the action of utilizing the storage is added to the behavior baseline of the code object. In an embodiment, a resource is associated with a code object, for example, where the code object is utilized to deploy the resource in a computing environment (e.g., a virtual instance is deployed based on a code object).

[0207] According to some embodiments, the behavior baseline is further generated based on data received from a sensor deployed on the resource. In an embodiment, the sensor is configured to detect runtime data, for example, from a memory space of a resource on which the sensor is deployed. In some embodiments, the sensor is configured to listen on a data link layer, a kernel space, a software abstraction layer interface, a hardware abstraction layer interface, a combination thereof, and the like.

[0208] In an embodiment, the sensor is configured to detect events, including an event which includes an identifier of a principal, an event including an identifier of a resource, a combination thereof, and the like.

[0209] In some embodiments, a behavior baseline is generated for a software service. For example, according to an embodiment, a behavior baseline is generated for a resource (e.g., a workload, an application, etc.) of the software service, and the behavior baseline of the software service is generated based on each component of the software service.

[0210] In an embodiment, a behavior baseline is generated based on cloud logs, on static analysis of code objects, on runtime data, on a combination thereof, and the like. For example, in an embodiment, an API call is present in a cloud log, which according to static analysis of a code object, should not have occurred.

[0211] At 1550, a runtime rule based on the behavior baseline is generated. For example, in an embodiment, the runtime rule is generated based on expected behavior of a resource, based on static analysis of the code object which was utilized to deploy the resource.

[0212] In the example above, a static analysis result includes updating a behavior baseline associated with the code object to indicate that a resource deployed based on the code object is capable of writing to a bucket having a specified identifier.

[0213] In an embodiment, a resource deployed based on the code object is associated with the behavior baseline, for example, by representing the code object and the resource on a security graph, and connecting together the representation of the code object and the representation of the resource, wherein the connection (e.g., the edge) indicates that the resource is deployed based on the code object.

[0214] According to an embodiment, the runtime rule is generated to indicate that where an event indicates an access to the bucket occurs, this is allowable behavior. In an embodiment, the runtime rule is generated to indicate that only events which correspond to a predetermined behavior baseline are allowable.

[0215] At 1560, a runtime sensor is deployed on the resource. In some embodiments, a runtime sensor is deployed on the resource in a cloud computing environment. In certain embodiments, the runtime sensor is configured to detect a runtime event on the resource. According to certain embodiments, the runtime sensor is deployed including the generated runtime rule on each resource in the cloud computing environment.

[0216] In an embodiment, each resource, software service, etc., has a representation in the security database which is connected to the representation of the code object. In another embodiment, the behavior profile is updated in response to detecting a plurality of events in an event log. Each of the plurality of events indicates an allowable action initiated by the resource, according to an embodiment.

[0217] At 1570, the generated runtime rule is applied. The runtime sensor is configured to apply the generated runtime rule, in an embodiment. In certain embodiments, a runtime sensor is deployed including the generated runtime rule on each resource in the cloud computing environment having a representation in the security database which is connected to the representation of the code object.

[0218] In an embodiment, the sensor includes a rule engine which is configured to apply rules, conditional rules, policies, a combination thereof, and the like. In some embodiments, the sensor is configured to apply rules which are generated based on a baseline behavior and rules received from another source.

[0219] At 1580, a suspicious activity is detected. In some embodiments, a suspicious activity is detected respective of the resource based on an application of the generated runtime rule by the runtime sensor on an event detected on the resource. In certain embodiments, an event is detected in an event log, the event including a data record having an identifier of the resource.

[0220] In another embodiment, the suspicious activity is analyzed to determine whether it constitutes a cybersecurity threat. In some embodiments, a remediation action is initiated based on the detected suspicious activity. In other embodiments, if the suspicious activity is deemed a cybersecurity threat a mitigation action is initiated.

[0221] According to an embodiment, a remediation action is initiated in response to detecting a suspicious activity. In an embodiment, a runtime rule violation is detected by the sensor. In some embodiments, the sensor is configured to generate a notification, for example, to a backend server, to indicate that the resource on which the sensor is deployed has violated a runtime rule.

[0222] In an embodiment, the remediation action includes blocking network traffic to a resource, blocking network traffic from a resource, revoking access to a resource, revoking access from a resource, revoking a permission of a principal, initiating cybersecurity inspection, a combination thereof, and the like.

[0223] In some embodiments, a behavior profile is enriched based on actions detected in a version control system, in a CI/CD environment, in a CLI, etc. For example, in an embodiment, an exception is generated for a detection rule based on a new version of a software service, a component thereof, and the like, pushed into production. In certain embodiments, the exception is triggered as a result of detecting a code change, a behavior change, and the like.

[0224] In certain embodiments, a resource is a component of a software service. In an embodiment, instances of the software service are deployed across multiple platforms (i.e., multiple different cloud service providers, multiple different software container clusters, etc.), such that a first service is deployed, for example, on a first Kubernetes cluster, and a second service is deployed on a second Kubernetes cluster. In an embodiment, the services are determined to be the same service based on their behavior baseline, based on code objects utilized to deploy resources of the software services, a combination thereof, and the like.

[0225] FIG. 16 is an example schematic diagram 1600 of a policy engine 190 according to an embodiment. The policy engine 190 includes a processing circuitry 1610 coupled to a memory 1620, a storage 1630, and a network interface 1640. In an embodiment, the components of the policy engine 190 may be communicatively connected via a bus 1650.

[0226] The processing circuitry 1610 may be realized as one or more hardware logic components and circuits. For example, and without limitation, illustrative 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), system-on-a-chip systems (SOCs), graphics processing units (GPUs), tensor processing units (TPUs), general-purpose microprocessors, microcontrollers, digital signal processors (DSPs), and the like, or any other hardware logic components that can perform calculations or other manipulations of information.

[0227] The memory 1620 may be volatile (e.g., random access memory, etc.), non-volatile (e.g., read only memory, flash memory, etc.), or a combination thereof. In an embodiment, the memory 1620 is an on-chip memory, an off-chip memory, a combination thereof, and the like. In certain embodiments, the memory 1620 is a scratch-pad memory for the processing circuitry 1610.

[0228] In one configuration, software for implementing one or more embodiments disclosed herein may be stored in the storage 1630, in the memory 1620, in a combination thereof, and the like. Software shall be construed broadly to mean any type of instructions, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Instructions may include code (e.g., in source code format, binary code format, executable code format, or any other suitable format of code). The instructions, when executed by the processing circuitry 1610, cause the processing circuitry 1610 to perform the various processes described herein.

[0229] The storage 1630 is a magnetic storage, an optical storage, a solid-state storage, a combination thereof, and the like, and is realized, according to an embodiment, as a flash memory, as a hard-disk drive, or other memory technology, or any other medium which can be used to store the desired information.

[0230] The network interface 1640 is configured to provide the policy engine 190 with communication with, for example, the inspection API 740, the software container cluster 710, and the like.

[0231] It should be understood that the embodiments described herein are not limited to the specific architecture illustrated in FIG. 16, and other architectures may be equally used without departing from the scope of the disclosed embodiments.

[0232] Furthermore, in certain embodiments the software container cluster 710 may be implemented with the architecture illustrated in FIG. 16. In other embodiments, other architectures may be equally used without departing from the scope of the disclosed embodiments.

[0233] The various embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage unit or computer readable medium consisting of parts, or of certain devices and/or a combination of devices. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (“CPUs”), a 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 either part of the microinstruction code or part of the application program, or any combination thereof, which may be executed by a CPU, whether or not such a computer or processor is explicitly shown. In addition, various other peripheral units may be connected to the computer platform such as an additional data storage unit and a printing unit. Furthermore, a non-transitory computer readable medium is any computer readable medium except for a transitory propagating signal.

[0234] All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the principles of the disclosed embodiment and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the disclosed embodiments, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure.

[0235] It should be understood that any reference to an element herein using a designation such as “first,” “second,” and so forth does not generally limit the quantity or order of those elements. Rather, these designations are generally used herein as a convenient method of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not mean that only two elements may be employed there or that the first element must precede the second element in some manner. Also, unless stated otherwise, a set of elements comprises one or more elements.

[0236] As used herein, the phrase “at least one of” followed by a listing of items means that any of the listed items can be utilized individually, or any combination of two or more of the listed items can be utilized. For example, if a system is described as including “at least one of A, B, and C,” the system can include A alone; B alone; C alone; 2A; 2B; 2C; 3A; A and B in combination; B and C in combination; A and C in combination; A, B, and C in combination; 2A and C in combination; A, 3B, and 2C in combination; and the like.