Context-based risk assessment of computing resource vulnerabilities

Abstract

A computer-implemented method can include: inspecting, using a processor, a set of container images associated with a pod, respectively; identifying, using the processor, a first subset of the pods containing vulnerabilities; classifying, using the processor, the first subset of the pods as primary infected pods; generating, using the processor, a first list of namespaces in which the primary infected pods are deployed within a network; examining, using the processor, network policies related to the first list of namespaces to determine secondary suspect pods that have the ability to communicate with the primary infected pods; generating, using the processor, a list of secondary suspect namespaces in which the secondary suspect pods are deployed within the network; identifying, using the processor, one or more secondary suspect pods that are in communication with one or more primary infected pods; and generating, using the processor, a list of secondary infected pods.

Description

BACKGROUND

[0001] The present disclosure relates to risk assessment of computer resource vulnerabilities, and more specifically, to context-based risk assessment of computer resource vulnerabilities.

[0002] Cloud computing applications (e.g., cloud-native applications) can include known vulnerabilities in their source code (e.g., through libraries they include) or in their environment (e.g., through other software they are packaged with in the same virtual machine (VM) or application container). Cloud-native applications are typically packaged in application containers (also referred to as “containers”) and managed by container clustering and orchestration middleware such as Kubernetes (K8s). A typical example of a vulnerable container is a container that has a version of Secure Shell (SSH) installed with known vulnerabilities.

[0003] Common Vulnerabilities and Exposures (CVEs) are a dictionary-type list of standardized names for computer resource vulnerabilities and other security exposure-related information. CVEs aim to standardize the names of all well-known computer resource vulnerabilities and security exposures. CVEs also assign a score to each vulnerability based on the severity of each vulnerability and the extent of damage that an attacker entity can cause after exploiting the vulnerability.

[0004] Some existing security technologies use CVE scores (e.g., lower CVE score = lower risk) and / or attack graphs to assess the risk of detected computer resource vulnerabilities in a network. However, a problem with such existing security technologies that use attack graphs to assess the risk of detected computer resource vulnerabilities is that they only consider networking elements that are capable of mitigating attacks (e.g., cyberattacks). Another problem with such existing security technologies is that they do not consider the deployment context of vulnerable computer resources (e.g., vulnerable containers, VMs, and / or another vulnerable computer resource) when assessing the risk and / or potential damage that a detected computer resource vulnerability can cause to one or more other computer resources. SUMMARY

[0005] The following presents a summary to provide a basic understanding of one or more embodiments of the application. This summary is not intended to identify key or important elements, or delineate any scope of any claims. Its sole purpose is to present concepts in a simplified form as a prelude to the more detailed description that is presented later. In one or more embodiments described herein, systems, computer-implemented methods, and / or computer program products that facilitate context-based risk assessment of computer resource vulnerabilities are described.

[0006] According to one embodiment, a system can include a processor that executes the following computer-executable components stored in a non-transitory computer-readable medium: an inspection component that inspects a set of container images respectively associated with pods, identifies a first subset of pods containing vulnerabilities, and classifies the first subset of pods as primary-infected pods; a namespace component that generates a first list of namespaces in which the primary-infected pods are deployed within a network; and a network component that checks network policies related to the first list of namespaces to determine secondary-suspect pods that have the ability to communicate with the primary-infected pods, wherein the namespace component generates a list of secondary-suspect namespaces in which the secondary-suspect pods are deployed within the network, the network component identifies one or more secondary-suspect pods that communicate with one or more primary-infected pods, and wherein the inspection component generates a list of secondary-infected pods. An advantage of such a system is that it can protect one or more computing resources in a network.

[0007] In some embodiments, the computer-executable components further include a checking component that checks specifications and privileges associated with the primary-infected pods and the secondary-infected pods to generate the list of suspect machines, primary-infected machines, and secondary-infected machines. An advantage of such a system is that it can protect one or more computing resources in a network.

[0008] According to another embodiment, a computer-implemented method can include inspecting, using a processor, a set of container images respectively associated with pods. The computer-implemented method can further include identifying, using the processor, a first subset of pods containing vulnerabilities. The computer-implemented method can further include classifying, using the processor, the first subset of pods as primary-infected pods. The computer-implemented method can also include generating, using the processor, a first list of namespaces in which the primary-infected pods are deployed within a network. The computer-implemented method can also include checking, using the processor, network policies related to the first list of namespaces to determine secondary-suspect pods that have the ability to communicate with the primary-infected pods. The computer-implemented method can also include generating, using the processor, a list of secondary-suspect namespaces in which the secondary-suspect pods are deployed within the network. The computer-implemented method can further include identifying, using the processor, one or more secondary-suspect pods that communicate with one or more primary-infected pods. The computer-implemented method can also include generating, using the processor, a list of secondary-infected pods. An advantage of such a computer-implemented method is that it can be implemented to protect one or more computing resources in a network.

[0009] In some embodiments, the above computer-implemented method can further include checking, using the processor, specifications and privileges associated with the primary infected pods and the secondary infected pods, and generating, using the processor, a list of suspicious machines, primary infected machines, and secondary infected machines. An advantage of this computer-implemented method is that it can be implemented to protect one or more computing resources in a network.

[0010] According to another embodiment, a computer program product includes a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor to cause the processor to inspect a set of container images respectively associated with pods. The program instructions are further executable by the processor to cause the processor to identify a first subset of the pods containing a vulnerability. The program instructions are further executable by the processor to cause the processor to classify the pods of the first subset as primary infected pods. The program instructions are further executable by the processor to cause the processor to generate a first list of name spaces in which the primary infected pods are deployed within a network. The program instructions are further executable by the processor to cause the processor to inspect network policies related to the first list of name spaces to determine secondary suspicious pods that have the ability to communicate with the primary infected pods. The program instructions are further executable by the processor to cause the processor to generate a list of secondary suspicious name spaces in which the secondary suspicious pods are deployed within the network. The program instructions are further executable by the processor to cause the processor to identify one or more secondary suspicious pods that are in communication with one or more primary infected pods. The program instructions are further executable by the processor to cause the processor to generate a list of secondary infected pods. An advantage of this computer program product is that it can be implemented to protect one or more computing resources in a network.

[0011] In some embodiments, the program instructions are further executable by the processor to cause the processor to check specifications and privileges associated with the primary infected pods and the secondary infected pods, and generate a list of suspicious machines, primary infected machines, and secondary infected machines. An advantage of this computer program product is that it can be implemented to protect one or more computing resources in a network. BRIEF DESCRIPTION OF DRAWINGS

[0012] Figure 1 、 Figure 2 、 Figure 4 、 Figure 5 、 Figure 6 、 Figure 8 and Figure 9 FIG. 1 shows a block diagram of an example, non-limiting system that can facilitate a context-based risk assessment of computer resource vulnerabilities, in accordance with one or more embodiments described herein.

[0013] Figure 3An example, non-limiting diagram illustrating a prior art system that generates Common Vulnerability and Exposure (CVE) scores that can be used to facilitate a context-based risk assessment of computer resource vulnerabilities, in accordance with one or more embodiments described herein is shown.

[0014] Figure 7 , Figure 10 , Figure 11 and Figure 12 An example, non-limiting diagram that can facilitate a context-based risk assessment of computer resource vulnerabilities, in accordance with one or more embodiments described herein is shown.

[0015] Figure 13 and Figure 14 A flow diagram of an example, non-limiting computer-implemented method that can facilitate a context-based risk assessment of computer resource vulnerabilities, in accordance with one or more embodiments described herein is shown.

[0016] Figure 15 A block diagram of an example, non-limiting operating environment in which one or more embodiments described herein can be facilitated is shown.

[0017] Figure 16 A block diagram of an example, non-limiting cloud computing environment in accordance with one or more embodiments of the subject disclosure is shown.

[0018] Figure 17 A block diagram of an example, non-limiting abstraction model layers in accordance with one or more embodiments of the subject disclosure is shown. DETAILED DESCRIPTION

[0019] The following detailed description is merely illustrative and is not intended to limit embodiments and / or the application or uses of embodiments. Furthermore, there is no intention to be bound by any expressed or implied information presented in the preceding Background or Summary sections, or the Details section.

[0020] One or more embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which like references are used to denote like elements, in which:

[0021] Given the above problems with existing security techniques, the present disclosure can be implemented to produce solutions to these problems in the form of a system, computer-implemented method, and / or computer program product that can facilitate a context-based risk assessment of computer resource vulnerabilities by: inspecting a set of container images respectively associated with pods; identifying a first subset of pods containing vulnerabilities; classifying the first subset of pods as primary infected pods; generating a first list of namespaces in which the primary infected pods are deployed within a network; examining network policies related to the first list of namespaces to determine secondary suspect pods that have the ability to communicate with the primary infected pods; generating a list of secondary suspect namespaces in which the secondary suspect pods are deployed within the network; identifying one or more secondary suspect pods that are in communication with one or more primary infected pods; and generating a list of secondary infected pods. Advantages of such a system, computer-implemented method, and / or computer program product are that they can be implemented to protect one or more computer resources in a network.

[0022] In some embodiments, the present disclosure can be implemented to produce solutions to the above problems in the form of a system, computer-implemented method, and / or computer program product that can further facilitate a context-based risk assessment of computer resource vulnerabilities by: inspecting specifications and privileges associated with the primary infected pods and the secondary infected pods, and generating a list of suspect machines, primary infected machines, and secondary infected machines. Advantages of such a system, computer-implemented method, and / or computer program product are that they can be implemented to protect one or more computer resources in a network.

[0023] As described herein, an “entity” can include a person, a client, a user, a computing device, a software application, an agent, a machine learning (ML) model, an artificial intelligence (AI) model, and / or another entity. As referred to herein, an “attacker entity” can include an entity as defined above that can exploit a vulnerability of a computing resource (e.g., a computing software and / or hardware resource) to attack (e.g., cyberattack) the computing resource using one or more attack techniques. As referred to herein, a “vulnerability” or “computing resource vulnerability” can include, for example, a library known to have a security issue, a configuration issue within a computing resource that can allow an attacker entity to attack the computing resource, and / or another vulnerability of a computing resource. As referred to herein, an “attack technique” can include a cyberattack technique. As referred to herein, a “security entity” and / or a “security analyst entity” can include an entity as defined above that can generate, develop, and / or implement one or more security measures (e.g., a threat model, a vulnerability management model, a risk management model, a penetration test, and / or another security measure) to prevent and / or mitigate exploitation of a computing resource vulnerability and / or an attack on a computing resource.

[0024] Figure 1 and Figure 2Block diagrams of example, non-limiting systems 100 and 200 are shown, each of which can facilitate context-based risk assessment of computer resource vulnerabilities, in accordance with one or more embodiments described herein. Systems 100 and 200 can each include a vulnerability risk assessment system 102. Figure 1 Vulnerability risk assessment system 102 of system 100 depicted in the middle can include a memory 104, a processor 106, an audit component 108, a namespace component 110, a network component 112, and / or a bus 114. Figure 2 Vulnerability risk assessment system 102 of system 200 depicted in the middle can further include an inspection component 202, a resource component 204, a permissions component 206, and / or a risk component 208.

[0025] It should be appreciated that embodiments of the application depicted in various figures disclosed herein are for illustration only and that the architecture of such embodiments is not limited to the systems, devices, and / or components depicted herein. For example, in some embodiments, system 100, system 200, and / or vulnerability risk assessment system 102 can also include computer and / or computing-based elements described herein with reference to operating environment 1500 and Figure 15 Various computer and / or computing-based elements described. In several embodiments, such computer and / or computing-based elements can be used in conjunction with one or more systems, devices, components, and / or computer-implemented operations shown and described in conjunction with Figure 1 , Figure 2 and / or other figures disclosed herein.

[0026] Memory 104 can store one or more computer and / or machine-readable, writeable, and / or executable components and / or instructions that, when executed by processor 106 (e.g., a classical processor, a quantum processor, and / or another type of processor), can facilitate performance of the operations defined by the executable components and / or instructions. For example, memory 104 can store computer and / or machine-readable, writeable, and / or executable components and / or instructions that, when processor 106 executes these components and / or instructions, can facilitate performance of various functions described herein related to vulnerability risk assessment system 102, audit component 108, namespace component 110, network component 112, inspection component 202, resource component 204, permissions component 206, risk component 208, and / or another component associated with vulnerability risk assessment system 102 described herein, with or without reference to the various figures of the subject disclosure.

[0027] The memory 104 can include volatile memory (e.g., random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), and / or another type of volatile memory) and / or non-volatile memory (e.g., read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), and / or another type of non-volatile memory) that can employ one or more memory architectures. Further examples of the memory 104 are described below with reference to the system memory 1516 and Figure 15 Further examples of the memory 104 are described below with reference to the system memory 1516 and

[0028] The processor 106 can include one or more types of processors and / or electronic circuits (e.g., classical processors, quantum processors, and / or another type of processor and / or electronic circuit) that can implement one or more computer and / or machine-readable, writable, and / or executable components and / or instructions that can be stored on the memory 104. For example, the processor 106 can perform various operations that can be specified by such computer and / or machine-readable, writable, and / or executable components and / or instructions, including, but not limited to, logic, control, input / output (I / O), arithmetic, and / or the like. In some embodiments, the processor 106 can include one or more central processing units, multi-core processors, microprocessors, dual microprocessors, microcontrollers, systems on a chip (SOCs), array processors, vector processors, quantum processors, and / or another type of processor. Further examples of the processor 106 are described below with reference to the processing unit 1514 and Figure 15 Further examples of the processor 106 are described below with reference to the processing unit 1514 and

[0029] The vulnerability risk assessment system 102, the memory 104, the processor 106, the audit component 108, the namespace component 110, the network component 112, the inspection component 202, the resource component 204, the permissions component 206, the risk component 208, and / or another component of the vulnerability risk assessment system 102 as described herein can be communicatively, electrically, operatively, and / or optically coupled to one another via the bus 114 to perform the functions of the system 100, the system 200, the vulnerability risk assessment system 102, and / or any components coupled thereto. The bus 114 can include one or more memory buses, memory controllers, peripheral buses, external buses, local buses, quantum buses, and / or another type of bus that can employ various bus architectures, and the like. Further examples of the bus 114 are described below with reference to the system bus 1518 and Figure 15 Further examples of the bus 114 are described below with reference to the system bus 1518 and

[0030] The vulnerability risk assessment system 102 can include any type of component, machine, device, facility, apparatus, and / or instrument that includes a processor and / or is capable of effective and / or operable communication with a wired and / or wireless network. All such embodiments are contemplated. For example, the vulnerability risk assessment system 102 can include a server device, a computing device, a general purpose computer, a special purpose computer, a quantum computing device (e.g., a quantum computer), a tablet computing device, a handheld device, a server class computing machine and / or database, a laptop computer, a notebook computer, a desktop computer, a cellular phone, a smart phone, a consumer appliance and / or instrument, an industrial and / or commercial device, a digital assistant, a multimedia internet enabled phone, a multimedia player, and / or another type of device.

[0031] The vulnerability risk assessment system 102 can be coupled (e.g., communicatively, electrically, operatively, optically, and / or via another type of coupling) to one or more external systems, sources, and / or devices (e.g., classical and / or quantum computing devices, communication devices, and / or another type of external system, source, and / or device) using wires and / or cables. For example, the vulnerability risk assessment system 102 can be coupled (e.g., communicatively, electrically, operatively, optically, and / or via another type of coupling) to one or more external systems, sources, and / or devices (e.g., classical and / or quantum computing devices, communication devices, and / or another type of external system, source, and / or device) using a data cable including, but not limited to, a high-definition multimedia interface (HDMI) cable, a recommended standard (RS) 232 cable, an Ethernet cable, and / or another data cable.

[0032] In some embodiments, the vulnerability risk assessment system 102 can be coupled (e.g., communicatively, electrically, operatively, optically, and / or via another type of coupling) to one or more external systems, sources, and / or devices (e.g., classical and / or quantum computing devices, communication devices, and / or another type of external system, source, and / or device) via a network. For example, such a network can include a wired and / or wireless network, including but not limited to a cellular network, a wide area network (WAN) (e.g., the Internet), or a local area network (LAN). The vulnerability risk assessment system 102 can use virtually any desired wired and / or wireless technology to communicate with one or more external systems, sources, and / or devices (e.g., computing devices), including but not limited to: wireless fidelity (Wi-Fi), global system for mobile communications (GSM), universal mobile telecommunications system (UMTS), worldwide interoperability for microwave access (WiMAX), enhanced general packet radio service (enhanced GPRS), third generation partnership project (3GPP) long term evolution (LTE), third generation partnership project 2 (3GPP2) ultra mobile broadband (UMB), high speed packet access (HSPA), Zigbee, and other 802.XX wireless technologies, and / or legacy telecommunication technologies, session initiation protocol (SIP), RF4CE protocol, WirelessHART protocol, 6L0WPAN (IPv6 over Low power Wireless Personal Area Networks), Z-Wave, ANT, Ultra-Wide Band (UWB) standard protocol, and / or other proprietary and non-proprietary communication protocols. Thus, in some embodiments, the vulnerability risk assessment system 102 can include hardware (e.g., central processing units (CPUs), transceivers, decoders, quantum hardware, quantum processors, and / or other hardware), software (e.g., a set of threads, a set of processes, software under execution, quantum pulse schedules, quantum circuits, quantum gates, and / or other software), or a combination of hardware and software that can facilitate the transfer of information between the vulnerability risk assessment system 102 and external systems, sources, and / or devices (e.g., computing devices, communication devices, and / or other types of external systems, and / or other software).

[0033] The vulnerability risk assessment system 102 can include one or more computers and / or machine-readable, writeable, and / or executable components and / or instructions that, when executed by the processor 106 (e.g., a classical processor, a quantum processor, and / or another type of processor), can facilitate performance of the operations defined by such components and / or instructions. Moreover, in many embodiments, as described herein with or without reference to the various drawings of the present subject disclosure, any components associated with the vulnerability risk assessment system 102 can include one or more computers and / or machine-readable, writeable, and / or executable components and / or instructions that, when executed by the processor 106, can facilitate performance of the operations defined by such components and / or instructions. For example, the audit component 108, the namespace component 110, the network component 112, the inspection component 202, the resource component 204, the permissions component 206, the risk component 208, and / or any other components associated with (e.g., communicatively, electronically, operatively, and / or optically coupled with and / or employed by) the vulnerability risk assessment system 102 as disclosed herein, can include such computers and / or machine-readable, writeable, and / or executable components and / or instructions. Thus, according to many embodiments, as disclosed herein, the vulnerability risk assessment system 102 and / or any components associated therewith can employ the processor 106 to execute such computers and / or machine-readable, writeable, and / or executable components and / or instructions to facilitate performance of one or more operations described herein with reference to the vulnerability risk assessment system 102 and / or any such components associated therewith.

[0034] The vulnerability risk assessment system 102 can facilitate (e.g., via the processor 106) performance of and / or operations associated with the audit component 108, the namespace component 110, the network component 112, the inspection component 202, the resource component 204, the permissions component 206, the risk component 208, and / or another component associated with the vulnerability risk assessment system 102 as disclosed herein. For example, as described in detail below, the vulnerability risk assessment system 102 can facilitate (e.g., via the processor 106): auditing a set of container images associated with a pod, respectively; identifying a first subset of pods containing vulnerabilities; classifying the first subset of pods as primary infected pods; generating a first list of namespaces in which the primary infected pods are deployed within a network; inspecting network policies related to the first list of namespaces to determine secondary suspect pods that have the ability to communicate with the primary infected pods; generating a list of secondary suspect namespaces in which the secondary suspect pods are deployed within the network; identifying one or more secondary suspect pods that are in communication with one or more primary infected pods; and / or generating a list of secondary infected pods.

[0035] In another example, as described in detail below, the vulnerability risk assessment system 102 can further facilitate (e.g., via the processor 106): examining the specifications and privileges associated with the primary infected pod and the secondary infected pod, and generating a list of suspicious machines, primary infected machines, and secondary infected machines; determining a total resource capacity that can be consumed by the respective infected containers associated with the primary infected pod and the secondary infected pod, and generating a total-capacity-at-risk measure; determining permissions associated with the respective infected containers; generating a contextual risk score and an absolute risk score associated with the primary infected pod and the secondary infected pod; assessing a limited capacity of at least one of a processor, a memory, or a disk; and / or generating a contextual risk score and an absolute risk score associated with the primary infected pod and the secondary infected pod, and generating a second contextual risk score and a second absolute risk score associated with the primary infected pod and the secondary infected pod based on one or more changes.

[0036] In facilitating the above-described operations, it should be appreciated that the vulnerability risk assessment system 102 can thereby contextualize the risk of a computing resource vulnerability by going beyond the risk scores provided by third parties such as CVEs and by going beyond the use of attack graphs that only consider networked elements that can mitigate attacks. For example, to contextualize the risk of a computing resource vulnerability, the vulnerability risk assessment system 102 can determine the ability of the computing resource to make the network and / or system configuration favorable to it by removing firewalls and security rules that isolate the computing resource and limit its ability to cause harm (e.g., via a cyber attack by an attacker entity). In another example, to contextualize the risk of a computing resource vulnerability, the vulnerability risk assessment system 102 can determine the permissions that the vulnerable computing resource has on a network such as, for example, a cloud computing management system, and can further examine the ability of the vulnerable computing resource to create, delete, and / or modify system defense elements (e.g., network policies, pod security policies, resource quotas, and / or another system defense element). In another example, to contextualize the risk of a computing resource vulnerability, the vulnerability risk assessment system 102 can determine the ability of the vulnerable computing resource to elevate its privileges and access (e.g., the ability to add network routes, change domain name system (DNS) entries, and / or another technique to elevate its privileges and access).

[0037] In the above examples, by determining the appropriate defense elements that can isolate the vulnerable computing resource and the ability of the vulnerable computing resource to modify these elements and extend their reach, the vulnerability risk assessment system 102 can compute a more accurate risk score (e.g., more accurate than a CVE score). For example, based on examining all the total potential on the vulnerable computing resource as described in the above examples, the vulnerability risk assessment system 102 can further examine its dependencies. For example, the vulnerability risk assessment system 102 can further examine: the number of replicas of the vulnerable computing resource (e.g., the number of container images); the mitigation mechanisms that the vulnerable computing resource cannot change; the communication patterns of the vulnerable computing resource with other computing resources in the network; and / or examine the ability of the immutable mechanism to mitigate the risk of the vulnerable computing resource. In these examples, based on the sum of all such analysis described above, the vulnerability risk assessment system 102 can further compute a contextual risk score (e.g., a context-based risk score) and / or an absolute risk score corresponding to the vulnerability of the computing resource.

[0038] In some embodiments, the vulnerability risk assessment system 102 can contextualize the risk of vulnerable containers in a network such as, for example, a cloud computing environment (e.g., the cloud computing environment 1650). To contextualize the risk of vulnerable containers in a cloud computing environment, the vulnerability risk assessment system 102 can employ the audit component 108, the namespace component 110, the network component 112, the inspection component 202, the resource component 204, the permissions component 206, and / or the risk component 208 to perform the following operations: 1) determine primary and secondary impacted containers; 2) determine primary and secondary impacted machines; 3) determine total resources consumable by the infected pods; 4) determine permissions of impacted containers within the API server; 5) determine the contextual and absolute risk of the vulnerability.

[0039] Determine primary and secondary affected containers

[0040] The audit component 108 can audit a set of container images associated with a pod, respectively, identify a first subset of pods containing the vulnerability, and classify the first subset of pods as primary infected pods. For example, the audit component 108 can determine the total number of containers with a given vulnerability (e.g., using the National Vulnerability Database (NVD), a knowledge base, a security report, a blog, and / or another resource). In this example, for each pod being evaluated, the audit component 108 can further inspect the container images and determine whether it contains the vulnerability. In this example, the audit component 108 can also generate a list of primary infected pods, which can include the first subset of pods containing the vulnerability (e.g., containing images of vulnerable containers) described above.

[0041] The namespace component 110 can determine a namespace in which to deploy a primary infected pod in the cloud computing environment, and can further generate a first list of such namespaces in which to deploy the primary infected pod in the cloud computing environment. The network component 112 can examine network policies related to the first list of namespaces to determine secondary suspect pods that have the ability to communicate with the primary infected pod, and can further generate a list of such secondary suspect pods (e.g., pods that do not have vulnerabilities but that pods with vulnerabilities can reach). The namespace component 110 can use the list of such secondary suspect pods to determine secondary suspect namespaces in which the secondary suspect pods are deployed in the cloud computing environment, and can further generate a list of such secondary suspect namespaces. In some embodiments, the namespace component 110 can exclude the first list of namespaces in which the primary infected pod is deployed from such list. The network component 112 can use the list of secondary suspect namespaces to examine network communication logs (e.g., using a data network packet analyzer application such as, for example, tcpdump and / or another data network packet analyzer application), and identify one or more secondary suspect pods that are in communication with one or more primary infected pods. In some embodiments, the audit component 108 can examine the secondary suspect namespaces in which such one or more secondary suspect pods are deployed in the cloud computing environment, and further derive and / or generate a list of secondary infected namespaces and / or a list of secondary infected pods from the list of secondary suspect namespaces. It should be appreciated that the audit component 108, the namespace component 110, and the network component 112 can repeat the above steps to derive more levels of infected pods, infected namespaces, suspect pods, and / or suspect namespaces beyond the above secondary.

[0042] 2) Determine primary and secondary affected machines

[0043] If the vulnerable container is not properly protected, then the pod with the vulnerable container can impact computing resources (e.g., virtual machines) in the cloud computing environment. A secure container is a container that runs without elevated privileges and is limited by system policies.

[0044] The inspection component 202 can inspect the specifications and privileges associated with each of the primary infected pods and each of the secondary infected pods to generate a list of suspicious machines, primary infected machines, and secondary infected machines (e.g., where such machines can include virtual machines). For example, the inspection component 202 can inspect the pod specifications and privileges associated with each of the primary infected pods and each of the secondary infected pods, and can further inspect the system policies of the machines (e.g., virtual machines) associated with such pods to generate such a list of suspicious machines, primary infected machines, and secondary infected machines. For example, the inspection component 202 can determine that a certain machine is a suspicious machine if it has a suspicious pod and it lacks system policies that properly protect it. In another example, the inspection component 202 can determine that a certain machine is a primary infected machine if it has a primary infected pod and it lacks system policies that properly protect it. In another example, the inspection component 202 can determine that a certain machine is a secondary infected machine if it has a secondary infected pod and it lacks system policies that properly protect it.

[0045] 3) Determine total resources that an infected pod can consume

[0046] Each pod can have a limited capacity of a given computing resource, such as, for example, a processor (e.g., CPU), memory, disk, and / or another computing resource. These boundaries are typically enforced by features such as, for example, cgroups. Containers that exceed their memory limits can be terminated by an out-of-memory manager (OOM). A typical security attack in a cloud computing environment is to cause an increase in compute utilization, thereby causing a service provider to pay more for the infrastructure.

[0047] The resource component 204 can determine a total resource capacity that respective infected containers associated with the primary infected pods and the secondary infected pods are capable of consuming to generate a total risk capacity metric. For example, the resource component 204 can calculate a total capacity of each computing resource that infected containers in the primary and secondary infected pods can consume. To calculate the total capacity of each computing resource that infected containers in the primary and secondary infected pods can consume, the resource component 204 can evaluate a limited capacity of each of such computing resources. For example, the resource component 204 can evaluate a limited capacity of at least one of a processor, memory, or disk. The resource component 204 can perform the above total capacity calculation based on an assumption of a total machine capacity of the computing resource that unlimited containers can consume or the total computing resource itself (e.g., in the case that a remote disk is not on the machine). In these examples, based on performing the above total capacity calculation for each infected container in the primary and secondary infected pods, the resource component 204 can thereby produce the total risk capacity metric.

[0048] 4) Determine affected container permissions in the API server

[0049] In Kubernetes (K8s), each pod has a service account. The service account has certain permissions and authenticates to the pod to communicate with the K8s application programming interface API server. If the service account is not constrained by role-based access control (RBAC) or attribute-based access control (ABAC), or if it has RBAC with administrative permissions, an attacker entity that gains access to such a pod can cause problems by performing one or more actions, such as, for example, creating, deleting, and / or modifying the pod, network policies, ingress rules, egress rules, and / or another feature.

[0050] The permissions component 206 can determine permissions associated with respective infected containers. For example, the permissions component 206 can determine a number (e.g., level) of API server permissions that an infected pod has in K8s. For example, the permissions component 206 can determine an amount of API server permissions that a primary infected pod, a secondary infected pod, and / or a secondary suspicious pod has in K8s. To determine permissions associated with an infected container, the permissions component 206 can inspect one or more security context settings associated with the infected container. For example, in a K8s construct, the permissions component 206 can inspect an access control list associated with the infected container. In this example, the permissions component 206 can inspect a user ID (UID) and a group ID (GID) associated with the infected container to determine permissions of the infected container related to accessing objects, such as files, in K8s.

[0051] 5) Determine contextual and absolute risk of a vulnerability

[0052] The risk component 208 can generate a contextual risk score and an absolute risk score associated with the primary infected pod and the secondary infected pod. In some embodiments, the risk component 208 can employ a rules-based technique to calculate such contextual risk score and / or absolute risk score, where rules of the rules-based technique define values that can be assigned to various risks and / or security measures associated with the primary infected pod and / or the secondary infected pod. In an example, the risk component 208 can combine findings from operations 1) - 4) above to generate the contextual risk score. For example, to generate the contextual risk score, the risk component 208 can combine findings from operations 1) - 4) as outlined in Table 1 below, where “base x threat” represents a number of elements measured in a certain group (e.g., a number of primary infected pods determined by the inspection component 108 as described above).

[0053] Table 1:

[0054] Measure Score Primary infected pod Base x threat + Secondary infected pod Base x threat + Secondary suspicious pod Base x threat + Primary infected namespace Base x threat + Secondary infected namespace Base x threat + Secondary suspicious namespace Base x threat + Primary infected machine Base x threat + Secondary infected machine Base x threat + Suspicious machine Base x threat + Total risk capacity measure Total x threat + Permission level on the API server Entity defined risk x threat

[0055] The risk component 208 can further generate an absolute risk score by combining the contextual risk score that can be calculated using Table 1 with an absolute risk of the computing resource vulnerability. For example, the risk component 208 can generate an absolute risk score by combining the contextual risk score that can be calculated using Table 1 with a CVE score of the computing resource vulnerability that can be obtained from a vulnerability data source (e.g., the National Vulnerability Database (NVD), a knowledge base, a security report, a blog, and / or another resource).

[0056] In some embodiments, the risk component 208 can dynamically generate a second contextual risk score and / or a second absolute risk score associated with the primary infected pod and the secondary infected pod based on one or more changes. For example, the risk component 208 can dynamically generate a second contextual risk score and / or a second absolute risk score associated with the primary infected pod and the secondary infected pod based on one or more changes including, but not limited to, a network policy change, a computing resource change, a configuration change, an infrastructure change, a security measure change, a permission change, a privilege change, a specification change, a communication pattern change (e.g., between computing resources in the network), and / or another change that can occur with respect to one or more computing resources in the network and / or with respect to the network itself.

[0057] In some embodiments, the risk component 208 can include and / or employ one or more machine learning (ML) and / or artificial intelligence (AI) models to generate the above-described contextual risk scores associated with the primary infected pod and the secondary infected pod. For example, the risk component 208 can include and / or employ an ML and / or AI model that has been trained to learn behaviors of a network (e.g., a cloud computing environment) and how a particular computing resource vulnerability affects the network and / or one or more computing resource components therein. For example, the risk component 208 can include and / or employ an ML and / or AI model that has been trained to learn, for example, network infrastructure and configurations, configurations of computing resource components in the network, and how these components communicate, security measures implemented for these components, and / or how the network and one or more components therein behave when various vulnerabilities in the network are exploited. In this example, based on obtaining (e.g., from the NVD) data describing a particular vulnerability associated with one or more computing resource components in the network, the risk component 208 can include and / or employ such trained ML and / or AI model to generate the above-described contextual risk score associated with such computing resource components.

[0058] To facilitate the above functionality (e.g., understanding how a particular computing resource vulnerability impacts a network and / or one or more computing resource components therein, and computing the above contextual risk score), the risk component 208 can include and / or employ ML and / or AI models that can perform classification, correlation, inference, and / or expression associated with artificial intelligence principles. For example, the risk component 208 can include and / or employ ML and / or AI models that can use automated classification systems and / or automated classification. In one example, the risk component 208 can include and / or employ ML and / or AI models that can use probability and / or statistics-based analysis (e.g., factoring into analysis utility and cost) to learn and / or generate inferences. The risk component 208 can include and / or employ ML and / or AI models that can use any suitable machine learning-based techniques, statistics-based techniques, and / or probability-based techniques. For example, the risk component 208 can include and / or employ ML and / or AI models that can use expert systems, fuzzy logic, support vector machines (SVM), hidden Markov models (HMM), greedy search algorithms, rule-based systems, Bayesian models (e.g., Bayesian networks), neural networks, other non-linear training techniques, data fusion, utility-based analysis systems, systems employing Bayesian models, etc. In another example, the risk component 208 can include and / or employ ML and / or AI models that are capable of performing a set of machine learning computations. For example, the risk component 208 can include and / or employ ML and / or AI models that can perform a set of clustering machine learning computations, a set of logistic regression machine learning computations, a set of decision tree machine learning computations, a set of random forest machine learning computations, a set of regression tree machine learning computations, a set of least squares machine learning computations, a set of instance-based machine learning computations, a set of regression machine learning computations, a set of support vector regression machine learning computations, a set of k-means machine learning computations, a set of spectral clustering machine learning computations, a set of rule learning machine learning computations, a set of Bayesian machine learning computations, a set of deep Boltzmann machine computations, a set of deep belief network computations, and / or a set of different machine learning computations.

[0059] In some embodiments, the vulnerability risk assessment system 102 can be associated with a cloud computing environment. For example, the vulnerability risk assessment system 102 can be associated with a cloud computing environment 1650 described below with reference to Figure 16 and / or one or more functional abstraction layers (e.g., hardware and software layer 1760, virtualization layer 1770, management layer 1780, and / or workload layer 1790) described below with reference to Figure 17 and / or one or more functional abstraction layers (e.g., hardware and software layer 1760, virtualization layer 1770, management layer 1780, and / or workload layer 1790) described below with reference to

[0060] The vulnerability risk assessment system 102 and / or components thereof (e.g., the audit component 108, the namespace component 110, the inspection component 202, the resource component 204, the permissions component 206, the risk component 208, and / or another component) can employ one or more of the following with respect to the cloud computing environment 1650 described below Figure 16 Figure 17 One or more functional abstraction layers (e.g., quantum software) described below to perform one or more operations in accordance with one or more embodiments of the subject disclosure described herein. For example, the cloud computing environment 1650 and / or such one or more functional abstraction layers can include one or more classical computing devices (e.g., a classical computer, a classical processor, a virtual machine, a server, and / or another classical computing device), quantum hardware, and / or quantum software (e.g., a quantum computing device, a quantum computer, a quantum processor, quantum circuit simulation software, superconducting circuits, and / or other quantum hardware and / or quantum software) that can be employed by the vulnerability risk assessment system 102 and / or components thereof to perform one or more operations in accordance with one or more embodiments. For example, the vulnerability risk assessment system 102 and / or components thereof can employ such one or more classical and / or quantum computing resources to perform one or more classical and / or quantum mathematical functions, calculations, and / or equations; compute and / or process scripts; algorithms; models (e.g., AI models, ML models, and / or another type of model); and / or another operation in accordance with one or more embodiments of the subject disclosure described herein.

[0061] It should be appreciated that while the present disclosure includes detailed descriptions of cloud computing, implementations of the teachings described herein are not limited to a cloud computing environment. Rather, embodiments of the application are capable of implementation in conjunction with any other type of computing environment now known or later developed.

[0062] Cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0063] The characteristics are as follows:

[0064] On-demand self-service: cloud consumers can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with the service's provider.

[0065] ​Broad network access: capabilities are available over a network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0066] Resource pooling: the provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the consumer generally has no control or knowledge over the exact location of the provided resources but can be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter).

[0067] Rapid elasticity: capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in. To the consumer, the provisions appear to be unlimited and can be purchased in any quantity at any time.

[0068] Measured service: cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported providing transparency for both the provider and consumer of the utilized service.

[0069] Service models are as follows:

[0070] Software as a Service (SaaS): the capability provided to the consumer is to use the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based e-mail). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0071] Platform as a Service (PaaS): the capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.

[0072] Infrastructure as a Service (laaS): the capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).

[0073] Deployment models are as follows:

[0074] Private cloud: the cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0075] Community cloud: the cloud infrastructure is shared by several organizations and supports mission-specific interests of the community. It can be managed by the organizations or a third party and can exist on-premises or off-premises.

[0076] Public cloud: the cloud infrastructure is made available to general public or a large industry group and is owned by an organization selling cloud services.

[0077] Hybrid cloud: the cloud infrastructure is a composition of two or more types of cloud (private, community, or public) that remain unique clouds but are bound together, allowing data and application portability (e.g., cloud bursting).

[0078] A cloud computing environment is service-oriented, focusing on statelessness, loose coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that consists of a network of interconnected nodes.

[0079] Figure 3 An example, non-limiting illustration 300 of a prior art system that generates a Common Vulnerability and Exposure (CVE) score that can be used to facilitate a context-based risk assessment of computer resource vulnerabilities is shown in accordance with one or more embodiments described herein. Repetitive description of like elements and / or processes employed in the various embodiments is omitted for sake of brevity.

[0080] Diagram 300 illustrates how a CVE score for a computing resource vulnerability can be calculated using several categories and / or metrics (e.g., base, impact exploitability, temporal, environmental modified impact, overall, exploitability metrics, impact metrics, and / or another category and / or metric). Diagram 300 illustrates how a CVE score can be calculated for a certain computing resource vulnerability in a network (denoted as “Network (AV: N)” in Figure 3 which can be combined by risk component 208 with the above-described contextual risk scores to calculate an absolute risk score, as described above with reference to the example embodiments depicted in Figure 1 and Figure 2

[0081] Figure 4 A block diagram of an example, non-limiting system 400 that can facilitate contextual-based risk assessment of computer resource vulnerabilities in accordance with one or more embodiments described herein is shown. Repetitive description of like elements and / or processes employed in various embodiments is omitted for sake of brevity.

[0082] As shown in the example embodiments depicted in Figure 4 , system 400 can include vulnerability risk assessment system 102. In this example embodiment, triage component 108 can: triage an image (denoted as “nginx-image” in Figure 4 ) of a container 402 (denoted as “Nginx container” in Figure 4 ) in a pod (denoted as “nginx-pod” in Figure 4 ​"nginx: 1.7.1"); identify vulnerability 404 (denoted as "CVE-2018-16844"); and / or classify the pod as a primary infected pod. In this example embodiment, based on identifying vulnerability 404, namespace component 110 can generate a list of namespaces (e.g., primary infected namespaces) in which the primary infected pod is deployed within the network. In this example embodiment, network component 112 can examine network policies related to such namespaces to determine one or more secondary suspicious pods that have the ability to communicate with the primary infected pod. In this example embodiment, based on such a determination by network component 112, namespace component 110 can generate a list of secondary suspicious namespaces in which the one or more secondary suspicious pods are deployed within the network. In this example embodiment, network component 112 can further identify one or more secondary suspicious pods that are actually in communication with the primary infected pod. In this example embodiment, triage component 108 can designate the one or more secondary suspicious pods that are actually in communication with the primary infected pod as one or more secondary infected pods. In this example embodiment, namespace component 110 can designate as secondary infected namespaces the namespaces in which such one or more secondary suspicious pods are actually in communication with the primary infected pod.

[0083] In Figure 4 the example embodiment illustrated, examination component 202 can examine the specifications and privileges associated with each of the primary infected pod and the one or more secondary infected pods to generate a list of suspicious machines, primary infected machines, and secondary infected machines (e.g., where such machines can include virtual machines). In this example embodiment, based on such a list of suspicious machines, primary infected machines, and secondary infected machines, resource component 204 can determine that infected container 402 (e.g., and / or the infected container image denoted as "nginx: 1.7.1" in Figure 4 the example embodiment illustrated) has a total resource capacity that consumes and generates a total risk capacity metric (e.g., a total risk capacity metric corresponding to a computing resource such as, for example, a processor, memory, or disk). In this example embodiment, permissions component 206 can determine permissions associated with infected container 402 to further determine a contextual attack risk associated with container 402. For example, permissions component 206 can determine permissions associated with container 402 in a particular network such as, for example, a cloud computing environment.

[0084] In Figure 4 the example embodiment illustrated, based on the findings of all of the above operations performed by the various components of vulnerability risk assessment system 102, risk component 208 can generate contextual risk scores and absolute risk scores associated with the primary infected pod and the secondary infected pods. For example, risk component 208 can use the findings of all of the above operations to generate contextual risk scores and absolute risk scores associated with the primary infected pod and the secondary infected pods by using, for example, the techniques described above with reference to Figure 1 andFigure 2 The example embodiments described in Table 1 described above, to generate a contextual risk score associated with the primary infected pod and the secondary infected pod. In this example, the risk component 208 can further combine such a contextual risk score with a CVE risk score 406 corresponding to the vulnerability 404 to compute an absolute risk score associated with the primary infected pod and the secondary infected pod. In this example, the vulnerability risk assessment system 102 and / or one or more components thereof can obtain the CVE risk score 406 from a vulnerability data source (e.g., the National Vulnerability Database (NVD), a knowledge base, a security report, a blog, and / or another resource).

[0085] Figure 5 A block diagram of an example, non-limiting system 500 that can facilitate contextual-based risk assessment of computer resource vulnerabilities in accordance with one or more embodiments described herein is shown. Repetitive description of like elements employed in various embodiments is omitted for sake of brevity.

[0086] The system 500 illustrates how the vulnerable pod can interact (e.g., communicate) and / or be coupled (e.g., operatively, communicatively, electrically, optically, and / or via another type of coupling) to one or more computing resources in a network (e.g., as illustrated by the black curved arrows in Figure 5 annotated in and by Figure 5 In some embodiments, the system 500 can include a Kubernetes (K8s) construct.

[0087] As illustrated by the example embodiments shown in Figure 5 In the namespace 502, the vulnerable pod 506a can interact and / or be coupled with the node 504a and / or an operating system infrastructure 508a (indicated as “OS-Infrastructure” in Figure 5 ) of the node 504a, in this example embodiment. The vulnerable pod 506a can also interact and / or be coupled with one or more other nodes 504b, one or more other pods 506b, and / or an operating system infrastructure 508b (indicated as “OS-Infrastructure” in Figure 5 ) of the one or more other nodes 504b, in this example embodiment. The vulnerable pod 506a can also interact and / or be coupled with a server such as, for example, a K8s Application Programming Interface (API) service 510 (referred to herein as a K8s API server 510), in this example embodiment.

[0088] According to one or more embodiments of the subject disclosure, the vulnerability risk assessment system 102 (e.g., via the network component 112, the inspection component 202, the permissions component 206, and / or another component) can determine one or more mitigation mechanisms associated with the vulnerable pod 506a (e.g., by inspecting network policies, norms, and / or privileges associated with the vulnerable pod 506a, permissions associated with the vulnerable pod 506a, and / or another technique). According to one or more embodiments of the subject disclosure, the vulnerability risk assessment system 102 (e.g., via the audit component 108, the namespace component 110, the network component 112, the permissions component 206, and / or another component) can determine other elements in communication with the vulnerable pod 506a to determine whether a vulnerability of the vulnerable pod 506a would affect other computing resource components in the system 500. According to one or more embodiments of the subject disclosure, the vulnerability risk assessment system 102 (e.g., via the risk component 208 and / or another component) can calculate a contextual risk score and an absolute risk score associated with the vulnerable pod 506a based on, for example, a CVE score corresponding to the vulnerability of the vulnerable pod 506a, one or more mitigation mechanisms associated with the vulnerable pod 506a, and whether the vulnerability of the vulnerable pod 506a affects other components in the system 500. For example, the risk component 208 can use Table 1 to calculate such a contextual risk score, as described in the example embodiments shown above with reference to Figure 1 and Figure 2

[0089] Figure 6 A block diagram illustrating an example, non-limiting system 600 that can facilitate context-based risk assessment of computer resource vulnerabilities according to one or more embodiments described herein is shown. Repetitive description of like elements employed in respective embodiments is omitted for sake of brevity.

[0090] The system 600 can include an example, non-limiting alternative embodiment of the system 500, where the system 600 illustrates one or more security measures (e.g., policies, privileges, permissions, norms, and / or another security measure) that can be implemented in a network for a vulnerable pod 506a. In some embodiments, the system 600 illustrates one or more security measures that can be implemented for a vulnerable pod 506a in a Kubernetes (K8s) construct.

[0091] As Figure 6 ​As shown in the example embodiments described above in reference to Figure 1 and Figure 2 , one or more security measures implemented for the vulnerable pod 506a (e.g., in a K8s construct) can include, but are not limited to: quotas (e.g., resource quotas that limit aggregate resource consumption in the namespace 502); limits (e.g., resource limits that limit specific resource consumption); network policies (e.g., K8s network policies that specify how the vulnerable pod 506a communicates with various network components); pod security policies (PSPs); secure enhanced Linux (SELinux); AppArmor security computing mode (Seccomp); role-based access control (RNAC); cluster roles; and / or another security measure. In accordance with one or more embodiments of the subject disclosure, the vulnerability risk assessment system 102 (e.g., via the network component 112, the inspection component 202, the resource component 204, the permissions component 206, the risk component 208, and / or another component) can identify and account for such one or more security measures in calculating the above-described contextual risk score and / or absolute risk score corresponding to the vulnerable pod 506a. For example, the vulnerability risk assessment system 102 (e.g., via the network component 112, the inspection component 202, the resource component 204, the permissions component 206, the risk component 208, and / or another component) can identify and account for such one or more security measures in calculating the contextual risk score corresponding to the vulnerable pod 506a using Table 1, as described above in reference to Figure 1 and Figure 2 .

[0092] Figure 7 An example, non-limiting illustration 700 is shown in accordance with one or more embodiments described herein, which can facilitate context-based risk assessment of computer resource vulnerabilities. Repetitive description of like elements and / or processes employed in the various embodiments is omitted for sake of brevity.

[0093] The illustration 700 shows how implementation of one or more security measures described above in reference to Figure 6 may mitigate risk associated with the vulnerable pod 506a. That is, for example, the illustration 700 shows how risk associated with the vulnerable pod 506a (e.g., as defined by a CVE score) can actually be smaller when the context associated with the vulnerable pod 506a is considered in a risk assessment (e.g., considered in a context-based risk assessment that can be performed by the vulnerability risk assessment system 102 in accordance with one or more embodiments of the subject disclosure).

[0094] In Figure 7In the example embodiment shown, base score 702 can include a baseline risk score, such as, for example, a CVE score corresponding to a vulnerability of vulnerable pod 506a. For example, base score 702 can include a baseline risk score that can be computed without considering a context associated with vulnerable pod 506a. For example, base score 702 can include a baseline risk score that is computed by existing vulnerability risk assessment techniques without considering a context, such as, for example, whether one or more of the above-described security measures have been implemented for vulnerable pod 506a.

[0095] In Figure 7 In the example embodiment shown, base score 704 can include a context-based risk score corresponding to vulnerable pod 506a that takes into account a context, such as, for example, whether one or more of the above-described security measures have been implemented for vulnerable pod 506a. In this example embodiment, base score 704 can include a context risk score and / or an absolute risk score corresponding to vulnerable pod 506a that can be computed by vulnerability risk assessment system 102 (e.g., via risk component 208) as described above with reference to the example embodiments depicted in Figure 1 and Figure 2 In this example embodiment, to compute base score 704, vulnerability risk assessment system 102 (e.g., via network component 112, inspection component 202, resource component 204, permissions component 206, risk component 208, and / or another component) can identify and consider the RBAC designation assigned to vulnerable pod 506a, as well as the quotas, limits, network policies, and / or pod security policy measures implemented for vulnerable pod 506a. For example, vulnerability risk assessment system 102 (e.g., via network component 112, inspection component 202, resource component 204, permissions component 206, risk component 208, and / or another component) can identify and consider the RBAC designation assigned to vulnerable pod 506a, as well as the quotas, limits, network policies, and / or pod security policy measures implemented for vulnerable pod 506a when computing a context risk score corresponding to vulnerable pod 506a using Table 1 as described above with reference to the example embodiments depicted in Figure 1 and Figure 2

[0096] In Figure 7 ​In the example embodiment shown, it should be appreciated that the vulnerability risk assessment system 102 can facilitate an improved risk assessment of the vulnerable pod 506a by considering the context associated with the vulnerable pod 506a. For example, it should be appreciated that the vulnerability risk assessment system 102 can facilitate an improved risk assessment of the vulnerable pod 506a by considering one or more security measures that have been or have not been implemented for the vulnerable pod 506a (e.g., whether or not quotas, limits, network policies, pod security policies, and / or RBAC have been implemented for the vulnerable pod 506a as described in the example embodiments described in Figure 7 the example embodiments described in Figure 7 In the example embodiments described in the example embodiments described in

[0097] Figure 8 A block diagram of an example, non-limiting system 800 that can facilitate a context-based risk assessment of computer resource vulnerabilities in accordance with one or more embodiments described herein is shown. Repetitive description of like elements employed in respective embodiments is omitted for sake of brevity.

[0098] The system 800 can include an example, non-limiting alternative embodiment of the system 600, where the system 800 illustrates one or more security measures (e.g., policies, privileges, permissions, specifications, and / or another security measure) that can be implemented for a vulnerable pod 506a in a K8s construct. As Figure 8 In the example embodiments described in the example embodiments described in

[0099] According to one or more embodiments of the subject disclosure, when computing the above-described contextual risk score and / or absolute risk score corresponding to vulnerable pod 506a, vulnerability risk assessment system 102 (e.g., via network component 112, inspection component 202, resource component 204, permissions component 206, risk component 208, and / or another component) can identify and consider such one or more security measures (e.g., RBAC designation, cluster role designation, and / or another security measure). For example, vulnerability risk assessment system 102 (e.g., via network component 112, inspection component 202, resource component 204, permissions component 206, risk component 208, and / or another component) can identify and consider the RBAC designation and / or cluster role designation of vulnerable pod 506a when computing the contextual risk score corresponding to vulnerable pod 506a using Table 1, as described in the example embodiments illustrated in Figure 1 and Figure 2 above.

[0100] Figure 9 A block diagram of an example, non-limiting system 900 that can facilitate context-based risk assessment of computer resource vulnerabilities according to one or more embodiments described herein is shown. Repetitive description of like elements employed in respective embodiments is omitted for sake of brevity.

[0101] System 900 can include an example, non-limiting alternative embodiment of system 600 and / or system 800, where system 900 illustrates an example of how some security measures are implemented for vulnerable pod 506a in a K8s construct without implementing other security measures. For example, in the example embodiments illustrated in Figure 9 RBAC and / or cluster role designation can be assigned to vulnerable pod 506a, while quota, limit, network policy, and / or pod security policy measures are not implemented for vulnerable pod 506a, as indicated by the “X” over each such security measure in Figure 9 .

[0102] As in Figure 9As annotated in the illustrated example embodiment, when certain security measures (e.g., quotas, limits, network policies, pod security policies, and / or another security measure) are not implemented for vulnerable pod 506a, it can enable vulnerable pod 506a to morph (e.g., modify, delete, escalate, and / or another morphing technique) one or more compute resource components of system 900 and / or system configurations of system 900. In this example embodiment, when such a particular security measure is not implemented for vulnerable pod 506a, vulnerability risk assessment system 102 can determine that the risk associated with vulnerable pod 506a is greater than if such a particular security measure were implemented. For example, in accordance with one or more embodiments of the subject disclosure, when computing the contextual risk score and / or the absolute risk score described above corresponding to vulnerable pod 506a, vulnerability risk assessment system 102 (e.g., via network component 112, inspection component 202, resource component 204, permissions component 206, risk component 208, and / or another component) can identify and consider RBAC and / or cluster role designations, as well as the lack of quota, limit, network policy, and / or pod security policy measures associated with vulnerable pod 506a. For example, vulnerability risk assessment system 102 (e.g., via network component 112, inspection component 202, resource component 204, permissions component 206, risk component 208, and / or another component) can identify and consider RBAC and / or cluster role designations, as well as the lack of quota, limit, network policy, and / or pod security policy measures associated with vulnerable pod 506a when computing the contextual risk score corresponding to vulnerable pod 506a using Table 1, as described above with reference to the example embodiments depicted in Figure 1 and Figure 2 above.

[0103] Figure 10 An example, non-limiting illustration 1000 is shown in accordance with one or more embodiments described herein that can facilitate a contextual-based risk assessment of computer resource vulnerabilities. Repetitive description of like elements and / or processes employed in various embodiments is omitted for sake of brevity.

[0104] Illustration 1000 shows how the lack of one or more security measures described above with reference to Figure 9 For example, illustration 1000 shows that the risk associated with vulnerable pod 506a (e.g., as defined by a CVE score) can actually be greater when the context associated with vulnerable pod 506a is considered in a risk assessment (e.g., considered in a contextual-based risk assessment that can be performed by vulnerability risk assessment system 102 in accordance with one or more embodiments of the subject disclosure).

[0105] exist Figure 10 In the example embodiment shown, the base score 1002 may include a baseline risk score, such as, for example, the CVE score corresponding to the vulnerability of vulnerable pod 506a. For example, the base score 1002 may include a baseline risk score that can be calculated without considering the context associated with vulnerable pod 506a. For example, the base score 1002 may include a baseline risk score calculated using existing vulnerability risk assessment techniques without considering context (such as, for example, whether one or more of the aforementioned security measures have already been implemented for vulnerable pod 506a).

[0106] exist Figure 10 In the example embodiment shown, the base score 1004 may include a context-based risk score corresponding to the vulnerable pod 506a, which takes into account context, such as whether one or more of the aforementioned security measures have been implemented for the vulnerable pod 506a. In this example embodiment, the base score 1004 may include a contextual risk score and / or an absolute risk score corresponding to the vulnerable pod 506a, which may be calculated by the vulnerability risk assessment system 102 (e.g., via risk component 208), as referenced above. Figure 1 and Figure 2 As illustrated in the example embodiment. In this example embodiment, in order to calculate the basic score 1004, the vulnerability risk assessment system 102 (e.g., via network component 112, inspection component 202, resource component 204, licensing component 206, risk component 208, and / or another component) can identify and consider the RBAC designation assigned to the vulnerable pod 506a, and the lack of quotas, restrictions, network policies, and / or pod security policy measures associated with the vulnerable pod 506a. For example, the vulnerability risk assessment system 102 (e.g., via network component 112, inspection component 202, resource component 204, licensing component 206, risk component 208, and / or another component) can identify and consider the RBAC designation assigned to the vulnerable pod 506a, and the lack of quotas, restrictions, network policies, and / or pod security policy measures associated with the vulnerable pod 506a, when calculating the context risk score corresponding to the vulnerable pod 506a using Table 1, as referenced above. Figure 1 and Figure 2 The example embodiment shown is illustrated.

[0107] exist Figure 10In the exemplary embodiments shown, it should be understood that the vulnerability risk assessment system 102 can facilitate risk assessment of improvements to the vulnerable pod 506a by considering the context associated with the vulnerable pod 506a. For example, it should be understood that the vulnerability risk assessment system 102 can facilitate risk assessment of improvements to the vulnerable pod 506a by considering one or more security measures that have been or have not yet been implemented for the vulnerable pod 506a (e.g., whether they have been implemented for such...). Figure 10 The risk assessment illustrates the implementation of quotas, restrictions, network policies, pod security policies, and / or RBACs (likely referring to pod security protocols) by the vulnerable pod 506a to facilitate improvements to the vulnerable pod 506a. (As shown in the original text...) Figure 10 As illustrated in the example embodiments described herein, it should be understood that the base score 1004 provides a more accurate risk assessment of the risks associated with the vulnerable pod 506a because when calculating the base score 1004, the vulnerability risk assessment system 102 can take into account the presence of RBAC designations assigned to the vulnerable pod 506a, as well as the lack of quotas, restrictions, network policies, and / or pod security policy measures associated with the vulnerable pod 506a.

[0108] Figure 11 An example, non-limiting illustration 1100, of one or more embodiments described herein is shown that facilitates context-based risk assessment of computer resource vulnerabilities. For brevity, repeated descriptions of similar elements and / or processes employed in the various embodiments are omitted.

[0109] Figure 1100 illustrates an etcd operator 1102 with one or more licenses 1104, which are defined for the etcd operator 1102 prior to its deployment. Figure 11 In the example embodiment shown, the etcd operator 1102 and one or more such licenses 1104 are in Figure 11 As illustrated in the illustration, in this example embodiment, the etcd operator 1102 may include a distributed key-value store that can store and manage certain information for running a distributed system (e.g., system configuration data, state data, metadata, and / or other information), wherein the name "etcd" originates from the folder named " / etc:" where such information is stored, and "d" stands for "distributed". In embodiments where the vulnerability risk assessment system 102 identifies (e.g., via verification component 108, namespace component 110, network component 112, and / or another component) a vulnerability corresponding to the etcd operator 1102, the vulnerability risk assessment system 102 (e.g., via network component 112, inspection component 202, resource component 204, permission component 206, risk component 208, and / or another component) can calculate a contextual risk score and / or absolute risk score corresponding to the etcd operator 1102 (as referenced above).Figure 1 and Figure 2 The one or more permissions 1104 defined for the etcd operator 1102 are further considered when computing the contextual risk score and / or the absolute risk score corresponding to the etcd operator 1102 (as described above with reference to the example embodiments depicted in FIGS. 1 and 2).

[0110] Figure 12 An example, non-limiting illustration 1200 is shown in accordance with one or more embodiments described herein, which can facilitate a context-based risk assessment of computer resource vulnerabilities. Repetitive description of like elements and / or processes employed in the various embodiments is omitted for sake of brevity.

[0111] The illustration 1200 shows an etcd operator 1202 having one or more permissions 1204 defined for it prior to deployment of the etcd operator 1202. In Figure 12 In the example embodiment shown, the etcd operator 1202 and such one or more permissions 1204 are in Figure 12 In the illustration shown, the etcd operator 1202 can include a distributed key-value store, which can hold and manage certain information to run a distributed system (e.g., system configuration data, state data, metadata, and / or other information), where the name “etcd” is derived from the folder named “ / etc:” that holds such information, and the “d” stands for “distributed.”

[0112] As Figure 12 depicted in the example embodiments described in Figure 12 and having a certain account denoted as “ServiceAccount” in Figure 12 In embodiments where the vulnerability risk assessment system 102 identifies (e.g., via the audit component 108, the namespace component 110, the network component 112, and / or another component) a vulnerability corresponding to the etcd operator 1202, the vulnerability risk assessment system 102 (e.g., via the network component 112, the check component 202, the resource component 204, the permission component 206, the risk component 208, and / or another component) can compute a contextual risk score and / or an absolute risk score corresponding to the etcd operator 1202, further considering the one or more permissions 1204 defined for the etcd operator 1202 (as described above with reference to the example embodiments depicted in FIGS. 1 and 2). Figure 1 and Figure 2 The one or more permissions 1204 defined for the etcd operator 1202 are further considered when computing the contextual risk score and / or the absolute risk score corresponding to the etcd operator 1202 (as described above with reference to the example embodiments depicted in FIGS. 1 and 2).

[0113] Figure 13A flow diagram illustrating an example, non-limiting computer-implemented method 1300 that can facilitate context-based risk assessment of computer resource vulnerabilities is shown in accordance with one or more embodiments described herein. Repetitive description of like elements employed in respective embodiments is omitted for sake of brevity.

[0114] At 1302, the computer-implemented method 1300 can include verifying (e.g., via the vulnerability risk assessment system 102 and / or the vetting component 108), using a processor (e.g., the processor 106), a vulnerability of a vulnerable computing resource component (e.g., the vulnerable pod 506a) in a network (e.g., the system 500, the cloud computing environment 950, and / or another network). For example, for a particular vulnerability, the vulnerability risk assessment system 102 and / or the vetting component 108 can verify a vulnerability description available on the National Vulnerability Database (NVD) and / or a corresponding CVE score.

[0115] At 1304, the computer-implemented method 1300 can include verifying (e.g., via the vulnerability risk assessment system 102, the vetting component 108, the namespace component 110, the network component 112, the inspection component 202, the resource component 204, and / or the permissions component 206), using a processor (e.g., the processor 106), an ability of the vulnerable computing resource component to change the network (e.g., an ability of the vulnerable computing resource component to change a configuration of the network). For example, by performing the above-referenced Figure 1 and Figure 2The example embodiments described in operations 1) - 5) above, the vulnerability risk assessment system 102 (e.g., via the audit component 108, the namespace component 110, the network component 112, the inspection component 202, the resource component 204, the permissions component 206, and / or the risk component 208) can contextualize the risk of the vulnerable computing resource component, and can further quantify such risk by using the table 1 calculations described above to calculate a contextual risk score. In this example, by auditing the communication path and the privileges, permissions, specifications, network policies, and / or other security contextual settings associated with the vulnerable computing resource component, and identifying the primary and secondary suspect and / or affected computing resource components as described above, the vulnerability risk assessment system 102 can thereby determine the extent to which the vulnerable computing resource component has the ability to create, delete, and / or modify one or more features of the network, such as, for example, a system defense element (e.g., a network policy, a pod security policy, a resource quota, and / or another system defense). In this example, the contextual risk score corresponding to such vulnerable computing resource component (e.g., calculated by the risk component 208 at operation 5) can quantify the overall (e.g., aggregated, integrated) ability of the vulnerable computing resource component to subvert the network (e.g., the configuration of the network), where, for example, a relatively high contextual risk score can be associated with a relatively high ability to change the network.

[0116] At 1306, the computer-implemented method 1300 can include auditing (e.g., via the vulnerability risk assessment system 102, the audit component 108, the namespace component 110, the network component 112, the inspection component 202, the resource component 204, and / or the permissions component 206), using a processor (e.g., the processor 106), an appropriate mechanism that the vulnerable computing resource component can change.

[0117] At 1308, the computer-implemented method 1300 can include verifying (e.g., via the vulnerability risk assessment system 102, the audit component 108, the namespace component 110, the network component 112, the inspection component 202, the resource component 204, and / or the permissions component 206), using the processor (e.g., the processor 106), the ability of the immutable mechanism to mitigate the risk. For example, by verifying the communication path and the privileges, permissions, specifications, network policies, and / or other security context settings associated with the vulnerable computing resource component, the vulnerability risk assessment system 102 can identify security context settings that can be changed by the vulnerable computing resource component and that cannot be changed by the vulnerable computing resource component. In this example, the vulnerability risk assessment system 102 can determine that these security context settings are sufficient to mitigate the risk that the vulnerable computing resource can perform certain unauthorized operations, for example, if the vulnerable computing resource component does not have escalated privileges and it is constrained by system policies (e.g., network policies) where such security context settings cannot be changed by the vulnerable computing resource component.

[0118] At 1310, the computer-implemented method 1300 can include verifying (e.g., via the vulnerability risk assessment system 102, the audit component 108, the namespace component 110, the network component 112, the inspection component 202, the resource component 204, and / or the permissions component 206), using the processor (e.g., the processor 106), the dependencies, the number of instances, and the communication pattern of the vulnerable computing resource component.

[0119] At 1312, the computer-implemented method 1300 can include calculating (e.g., via the vulnerability risk assessment system 102 and / or the risk component 208), using the processor (e.g., the processor 106), a contextualized risk score corresponding to the vulnerable computing resource component (e.g., the risk component 208 can calculate the contextualized risk score using Table 1 described above with reference to the example embodiments depicted in Figure 1 and Figure 2 At 1312, the computer-implemented method 1300 can include calculating (e.g., via the vulnerability risk assessment system 102 and / or the risk component 208), using the processor (e.g., the processor 106), a contextualized risk score corresponding to the vulnerable computing resource component (e.g., the risk component 208 can calculate the contextualized risk score using Table 1 described above with reference to the example embodiments depicted in

[0120] Figure 14 A flow diagram of an example, non-limiting computer-implemented method 1400 that can facilitate a contextual-based risk assessment of a computer resource vulnerability is shown in accordance with one or more embodiments described herein. Repetitive description of like elements and / or processes employed in the various embodiments is omitted for sake of brevity.

[0121] At 1402, the computer-implemented method 1400 can include auditing (e.g., via the vulnerability risk assessment system 102 and / or the audit component 108), using the processor (e.g., the processor 106), a set of container images associated with a pod, respectively.

[0122] At 1404, the computer-implemented method 1400 can include identifying (e.g., via the vulnerability risk assessment system 102 and / or the audit component 108), using the processor (e.g., the processor 106), a first subset of pods containing vulnerabilities.

[0123] At 1406, the computer-implemented method 1400 can include classifying (e.g., by the vulnerability risk assessment system 102 and / or the audit component 108), using the processor (e.g., the processor 106), the first subset of pods as primary infected pods.

[0124] At 1408, the computer-implemented method 1400 can include generating (e.g., via the vulnerability risk assessment system 102 and / or the namespace component 110), using the processor (e.g., the processor 106), a first list of namespaces in which the primary infected pods are deployed within the network.

[0125] At 1410, the computer-implemented method 1400 can include examining (e.g., via the vulnerability risk assessment system 102 and / or the network component 112), using the processor (e.g., the processor 106), network policies related to the first list of namespaces to determine secondary suspect pods that have the ability to communicate with the primary infected pods.

[0126] At 1412, the computer-implemented method 1400 can include generating (e.g., via the vulnerability risk assessment system 102 and / or the namespace component 110), using the processor (e.g., the processor 106), a list of secondary suspect namespaces in which the secondary suspect pods are deployed within the network.

[0127] At 1414, the computer-implemented method 1400 can include identifying (e.g., via the vulnerability risk assessment system 102 and / or the network component 112), using the processor (e.g., the processor 106), one or more secondary suspect pods that are in communication with one or more primary infected pods.

[0128] At 1416, the computer-implemented method 1400 can include generating (e.g., via the vulnerability risk assessment system 102 and / or the audit component 108), using the processor (e.g., the processor 106), a list of secondary infected pods.

[0129] The vulnerability risk assessment system 102 can be associated with various technologies. For example, the vulnerability risk assessment system 102 can be associated with computing system security and / or risk assessment technologies, ML and / or AI model technologies, cloud computing technologies, and / or other technologies.

[0130] The vulnerability risk assessment system 102 can provide technical improvements to systems, devices, components, operational steps, and / or processing steps associated with the various techniques described above. For example, the vulnerability risk assessment system 102 can perform a context-based risk assessment on a vulnerable computer resource in a network to more accurately identify and / or quantify a risk associated with the vulnerable computer resource (e.g., more accurately identify and / or quantify the risk when compared to static CVE scores used by current computing system security and / or risk assessment techniques). In this example, by performing such a context-based risk assessment on such a vulnerable computer resource, the vulnerability risk assessment system 102 can thereby facilitate improved protection of one or more computer resources in a network by enabling a security analyst entity to implement and / or prioritize one or more security measures based on the context-based risk assessment described above. In this example, by performing such a context-based risk assessment on such a vulnerable computer resource, the vulnerability risk assessment system 102 can thereby determine the vulnerable computer resource’s ability to morph a network configuration to its advantage. In this example, such a security analyst entity can then implement and / or prioritize one or more security measures to eliminate or mitigate such ability.

[0131] The vulnerability risk assessment system 102 can provide technical improvements to processing units associated with the vulnerability risk assessment system 102. For example, the one or more computer resources described above can include a processor (e.g., a CPU, the processor 106, and / or another type of processor). In this example, by performing the context-based risk assessment described above that can be used to implement and / or prioritize one or more security measures to protect one or more computer resources in a network, the vulnerability risk assessment system 102 can thereby facilitate improved protection of the processing unit (e.g., improved protection against potential cyberattacks on the processing unit by exploiting the vulnerable computer resource in the network).

[0132] A practical application of the vulnerability risk assessment system 102 is that it can be implemented by a security analyst entity to protect one or more computer resources in a network from cyberattacks that can be performed by exploiting a vulnerable computer resource in the network. For example, a practical application of the vulnerability risk assessment system 102 is that it can be implemented by a security analyst entity to generate a threat model, a vulnerability management model, and / or a risk management model based on the risk assessment described above of the vulnerable computer resource.

[0133] It should be appreciated that the vulnerability risk assessment system 102 provides a new approach driven by relatively new cyber attack techniques that exploit one or more vulnerabilities of one or more computing resources. For example, the vulnerability risk assessment system 102 provides a new approach that more accurately identifies and / or quantifies (e.g., automatically, without human input) risk associated with vulnerable computing resources (e.g., more accurately identifies and / or quantifies risk when compared to static CVE scores used by current computing system security and / or risk assessment techniques).

[0134] The vulnerability risk assessment system 102 can employ hardware or software to solve highly technical problems that are not abstract and cannot be performed as a set of mental acts by a human. In some embodiments, one or more processes described herein can be performed by one or more special purpose computers (e.g., special purpose processing units, special purpose classical computers, special purpose quantum computers, and / or another type of special purpose computer) to perform defined tasks related to the various technologies described above. The vulnerability risk assessment system 102 and / or components thereof can be used to solve new problems that arise through the use of the technological advancements described above, quantum computing systems, cloud computing systems, computer architectures, and / or another technology.

[0135] It should be appreciated that the vulnerability risk assessment system 102 can utilize various combinations of electrical components, mechanical components, and circuits that cannot be replicated in or performed by a human brain because the various operations that can be performed by the vulnerability risk assessment system 102 and / or components thereof are operations that are greater than the capabilities of a human brain. For example, the amount of data processed by the vulnerability risk assessment system 102 in a particular time period, the speed at which such data is processed, or the type of data processed can be greater than, faster than, or different than the amount of data, speed, or type of data that a human can process in the same time period.

[0136] According to several embodiments, the vulnerability risk assessment system 102 can also be fully operable to perform one or more other functions (e.g., fully powered on, fully executed, and / or another function) while also performing the various operations described herein. It should be appreciated that such simultaneous multiple operation performance is beyond the capabilities of the human mind. It should also be appreciated that the vulnerability risk assessment system 102 can include information that is not possible for an entity such as a human user to obtain manually. For example, the type, amount, and / or variety of information included in the vulnerability risk assessment system 102, the audit component 108, the namespace component 110, the network component 112, the inspection component 202, the resource component 204, the permissions component 206, and / or the risk component 208 can be more complex than information that an entity such as a human user can obtain manually.

[0137] For simplicity of explanation, the computer-implemented methodologies are depicted and described as a series of acts. It is to be understood and appreciated that the subject innovation is not limited by the acts illustrated and / or by the order of acts, for example acts can occur in various orders and / or concurrently, and with other acts not presented and described herein. Furthermore, not all illustrated acts can be required to implement the computer-implemented methodologies in accordance with the disclosed subject matter. In addition, those skilled in the art will understand and appreciate that the computer-implemented methodologies could alternatively be represented as a series of interrelated states utilizing a state diagram or events, for example. Additionally, it should be further appreciated that the computer-implemented methodologies disclosed herein and throughout this specification are capable of being stored on an article of manufacture to facilitate transporting and transferring such computer- implemented methodologies to computing devices. The term article of manufacture, as used herein, is intended to encompass a computer program accessible from a computer-readable device or storage media.

[0138] To provide a context for the various aspects of the disclosed subject matter, Figure 15 and the following discussion is intended to provide a general description of a suitable environment in which the various aspects of the disclosed subject matter can be implemented. Figure 15 A block diagram of an example, non-limiting operating environment in which one or more embodiments described herein can be facilitated is shown. Repetitive description of like elements employed in other embodiments described herein is omitted for sake of brevity.

[0139] With reference to Figure 15 A suitable operating environment 1500 for implementing various aspects of the disclosure can also include the computer 1512. The computer 1512 can also include a processing unit 1514, a system memory 1516, and a system bus 1518. The system bus 1518 couples system components including, but not limited to, the system memory 1516 to the processing unit 1514. The processing unit 1514 can be any of various available processors. Dual microprocessors and other multiprocessor architectures can also be employed as the processing unit 1514. The system bus 1518 can be any of several types of bus structures including memory buses or memory controllers, peripheral buses or external buses, and / or a local bus using any of a variety of bus architectures including, but not limited to, Industrial Standard Architecture (ISA), Micro Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Card Bus, Universal Serial Bus (USB), Advanced Graphics Port (AGP), Firewire (IEEE 1394), and Small Computer Systems Interface (SCSI).

[0140] The system memory 1516 can also include volatile memory 1520 and nonvolatile memory 1522. The basic input / output system (BIOS), containing the basic routines to transfer information between elements within the computer 1512, such as during start-up, is stored in nonvolatile memory 1522. The computer 1512 can further include removable / non-removable, volatile / non-volatile computer storage media. For example, Figure 15 A disk storage 1524 is also shown. A disk storage 1524 can also include, but is not limited to, devices like a magnetic disk drive, floppy disk drive, tape drive, Jaz drive, Zip drive, LS-100 drive, flash memory card, or a memory stick. The disk storage 1524 also can include a storage medium Figure 15 Software can also be transmitted into the computer 1512 via a communication interface 1530, such as a wireless communication interface over the Internet, over a pieces of a distributed system, and the like. The communication interface 1530 sends and receives electrical, electromagnetic or optical signals that carry information and can be implemented using a modem, satellite link, and the like. These signals can also be carried on a communication medium, which can be a fiber optic cable, a metallic wire, an electrical conductor, and the like.

[0141] The system applications 1530 are given the control of various aspects of the resource management by the operating system 1528, through program modules 1532 and program data 1534, e.g., stored both in the system memory 1516 and / or the disk storage 1524. It is to be appreciated that this disclosure can be implemented with various operating systems or combinations of operating systems. A user enters commands or information into the computer 1512 through input device(s) 1536. Input devices 1536 include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touchpad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit 1514 through the system bus 1518 via interface port(s) 1538. Interface port(s) 1538 include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s) 1540 use some of the same type of ports as input device(s) 1536. Thus, for example, a USB port can be used to provide input to computer 1512, and to output information from computer 1512 to an output device 1540. Output adapter 1542 is provided to illustrate that there are some output devices 1540 like monitors, speakers, and printers, among other output devices 1540, that require special adapters. The output adapters 1542 include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device 1540 and the system bus 1518. It should be noted that other devices and / or systems of devices provide both input and output capabilities such as remote computer(s) 1544.

[0142] The computer 1512 can operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 1544. The remote computer 1544 can be a computer, a server, a router, a network PC, a workstation, a microprocessor-based device, a peer device or other common network node, and typically can also include many or all of the elements described relative to the computer 1512, although, for purposes of brevity, only a memory storage device 1546 is illustrated. The remote computer 1544 is logically connected to the computer 1512 through a network interface 1548 and then physically connected via a communication connection 1550. The network interface 1548 encompasses wire and / or wireless communication networks such as local-area networks (LAN), wide-area networks (WAN), cellular networks, and / or another wired and / or wireless communication networks. LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet, Token Ring and / or the like. WAN technologies include, but are not limited to, point-to-point links, circuit-switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet-switching networks, and Digital Subscriber Lines (DSL). The communication connection 1550 refers to the hardware / software employed to connect the network interface 1548 to the system bus 1518. While the communication connection 1550 is shown for illustrative clarity inside the computer 1512, it can also be external to the computer 1512. The hardware / software for connecting the network interface 1548 to the system bus 1518 can also include internal and external technologies for wired and / or wireless communication, such as, for example, including conventional telephone-grade modems, cable modems, and DSL modems, ISDN adapters, and Ethernet cards.

[0143] Referring now to the Figure 16 , an illustrative cloud computing environment 1650 is depicted. As shown, cloud computing environment 1650 includes one or more cloud computing nodes 1610 with which a cloud consumer can engage with to use the cloud computing nodes. Although a cloud computing node 1610 is shown with the cloud computing environment 1650, the cloud computing node 1610 can also be located within the cloud computing environment 1650. In this description and the following claims, the term "cloud computing" is used to describe a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and Figure 16 services), which can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service. This cloud model can be composed of various characteristics (e.g., on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth) that can benefit the cloud consumer deployed efforts. Figure 16The types of computing devices 1654A-N shown in FIG. 16 are intended to be illustrative only and the computing nodes 1610 and cloud computing environment 1650 can communicate with any type of computerized device over any type of network and / or network addressable connection (e.g., using a web browser).

[0144] Referring now to Figure 17 , a set of functional abstraction layers are shown provided by cloud computing environment 1650 Figure 16 . It should be understood that Figure 17 the components, layers, and functions shown in FIG. 16 are intended to be illustrative only and embodiments of the application are not limited in scope to such. As shown, the following layers and respective functions are provided:

[0145] Hardware and software layer 1760 includes hardware and software components. Examples of hardware components include: mainframes 1761; RISC (Reduced Instruction Set Computer) architecture based servers 1762; servers 1763; blade servers 1764; storage devices 1765; and networks and networking components 1766. In some embodiments, software components include network application server software 1767; database software 1768; quantum platform routing software (not shown in Figure 17 ) and / or quantum software (not shown in Figure 17 ).

[0146] Virtualization layer 1770 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 1771; virtual storage 1772; virtual networks 1773, including virtual private networks; virtual applications and operating systems 1774; and virtual clients 1775.

[0147] In one example, management layer 1780 can provide the functions described below. Resource provisioning 1781 provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment. Metering and Pricing 1782 provide cost tracking as resources are utilized within the cloud computing environment, and cost can be billed or invoiced to consumers according to the usage of the resources. In one example, these resources can include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal 1783 is used by a consumer to request cloud computing resources. Service level management 1784 provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment 1785 provide pre-arrangement for, and procurement of, cloud computing resources according to demand that is anticipated from the SLA planning. Cloud computing environment 1650 is shown in the example to include software that creates one or more platforms to use the cloud computing resources. For example, the platforms can create

[0148] Workload layer 1790 provides examples of functionality that can be used by the cloud computing environment. Non-limiting examples of workloads and functions that can be provided from this layer include: mapping and navigation 1791; software development and lifecycle management 1792; virtual classroom education delivery 1793; data analytics processing 1794; transaction processing 1795; and vulnerability risk assessment software 1796.

[0149] The present application can be a system, a method, an apparatus and / or a computer program product at any possible technical detail level of integration. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present application. The computer readable storage medium can be a tangible device that can retain and store instructions for execution by an instruction execution device. The computer readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non- exhaustive list of more specific examples of the computer readable storage medium can also include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0150] The computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device. Computer readable program instructions for carrying out operations of the present application can be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions can execute entirely on the user's computing / processing device, partly on the user's computing / processing device, as a stand-alone software package, partly on the user's computing / processing device and partly on a remote computing / processing device or entirely on the remote computing / processing device or server. In the latter scenario, the remote computing / processing device can be connected to the user's computing / processing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspect(s) of the present application.

[0151] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational acts to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0152] The flow and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flow and block diagrams can represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block in the block and / or flow diagrams and combinations of blocks in the block and / or flow diagrams can be implemented by special purpose hardware-based systems that perform the specified functions or acts or combinations of special purpose hardware and computer instructions.

[0153] While the subject matter has been described above in the general context of computer-executable instructions of a computer program product that runs on a computer and / or computers, those skilled in the art will recognize that the disclosure also can be implemented in combination with other program modules. Generally, program modules include routines, programs, components, data structures, and / or other program modules that perform particular tasks and / or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the inventive computer-implemented methods can be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, minicomputers, mainframe computers, as well as computers, hand-held computing devices (e.g., PDA, phone), microprocessor-based or programmable consumer or industrial electronics, and the like. The illustrated aspects can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. However, some, if not all, of the aspects of this disclosure can be practiced on stand-alone computers. In a distributed computing environment, program modules can be located in local and remote memory storage devices. For example, in one or more embodiments, computer-executable components can be executed from memory that can include or consist of one or more distributed memory units. As used herein, the terms “memory” and “memory unit” are interchangeable. Moreover, one or more embodiments described herein can execute code of computer-executable components in a distributed manner, e.g., multiple processors combine or work in concert to execute code from one or more distributed memory units. As used herein, the term “memory” can include a single memory or memory unit at one location or multiple memories or memory units at one or more locations.

[0154] As used in this application, the terms "component," "system," "platform," "interface," and the like can refer to and / or can include a computer-related entity or an entity that is related to an operational machine with one or more specific functionalities. The entities disclosed herein can be either hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and / or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and / or thread of execution and a component can be localized, co-resident, and / or distributed amongst one or more computers. In another example, a component can be a software application, piece of code, an agent, or other software implementation, executing on a server, user computer, network computer, wireless device, network router, switch or bridge, or the like. Where multiple components implement the same or similar functionality, the various entities disclosed herein can also be arranged to act as a server group, home server, host server, or similar terminology.

[0155] Moreover, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or." That is, unless specified otherwise, or clear from context, "X employs A or B" is intended to mean any of the natural inclusive permutations. That is, if X uses A; or X uses B; or X uses both A and B, then "X employs A or B" is satisfied under any of the foregoing instances. Moreover, articles "a" and "an" as used in the subject specification and annexed drawings should generally be construed to mean "one or more" unless specified otherwise or clear from context to be directed to a singular form. As used herein, the term "example" and / or "exemplary" are utilized to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited to the examples provided herein. In addition, any aspect or design described in the "example" and / or "exemplary" section are intended to be illustrative only and not necessarily limiting of other aspects of the subject matter described herein. Unless otherwise stated, all multiple bibliographic combinations are specifically contemplated.

[0156] As used in the subject specification, the term "processor" can refer to substantially any computing processing unit or device, including, but not limited to, a single-core processor; single-processor with software multithread execution capability; multi-processor; multi-core processor; multi-core processor with software multithread execution capability; multi-core processor with hardware multithread technology; parallel platforms; and parallel platforms with distributed shared memory. Additionally, a processor can refer to an integrated circuit, an application specific integrated circuit (ASIC), a digital signal processor (DSP), a field programmable gate array (FPGA), a programmable logic controller (PLC), a complex programmable logic device (CPLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. Furthermore, a processor can utilize nano- scale architectures such as, but not limited to, molecular and quantum-dot based transistors, switches and gates, in order to optimize space usage or enhance performance of user equipment. A processor can also be implemented as a combination of computing processing units. In the present disclosure, terms such as "store," "storage," "data store," data storage," "database," and substantially any other information storage component relevant to operation and functionality of a component are utilized to refer to "memory components," entities embodied in a "memory," or components including memory. It is to be appreciated that memory and / or memory components described herein can be volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. By way of example, and without limitation, nonvolatile memory can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), flash memory, or nonvolatile random access memory (RAM) (e.g., ferroelectric RAM (FeRAM)). Volatile memory can include RAM, which can act as external cache memory, for example. By way of illustration and not limitation, RAM can be obtained from a plurality of sources, such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double-data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), direct Rambus RAM (DRRAM), direct Rambus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM). Moreover, memory components of systems or computer-implemented methods disclosed herein are intended to include, without being limited to including, these and any other suitable types of memory.

[0157] The above-described examples merely include examples of systems and computer- implemented methods. Of course, not every combination of components or computer-implemented methods can be described in order to describe the present disclosure, but one of ordinary skill in the art can recognize many further combinations and permutations of the present disclosure are possible. Moreover, in terms of the term "comprising", "containing", "including", "having" and the like, these terms are intended to be equivalent in that they are used in the claims as transitional phrases that are open-ended, meaning that they do not exclude additional, unrecited elements or method steps.

[0158] The description of the various embodiments has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application, or technical improvement over technologies found in the marketplace, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A computer system, comprising: A processor that executes the following computer-executable components stored in a non-transitory computer-readable medium: The inspection component inspects a set of container images associated with a pod, identifies a first subset of pods containing vulnerabilities, and classifies the first subset of pods as primary infected pods. Namespace component, which generates a first list of namespaces within the network in which the primary infection pods are deployed; and A network component examines network policies associated with a first list of namespaces to determine secondary suspicious pods capable of communicating with primary infected pods, wherein the namespace component generates a list of secondary suspicious namespaces in which the secondary suspicious pods are deployed within the network, the network component identifies one or more secondary suspicious pods communicating with one or more primary infected pods, and wherein the verification component generates the list of secondary infected pods based on the one or more secondary suspicious pods communicating with one or more primary infected pods; as well as The risk component generates contextual risk scores and absolute risk scores associated with primary and secondary infection pods. The context risk score is generated based on a measurement of at least one of the following: the number of primary infected pods, the number of secondary infected pods, the number of secondary suspicious pods, the number of primary infected namespaces, the number of secondary infected namespaces, the number of secondary suspicious namespaces, the number of primary infected machines, the number of secondary infected machines, the number of suspicious machines, the total risk capacity metric, and the permission level on the API server. The absolute risk score is generated based on the context risk score and the common vulnerability and exposure CVE scores corresponding to the vulnerability.

2. The computer system of claim 1 further includes an inspection component that inspects specifications and privileges associated with the primary and secondary infected pods to generate a list of suspicious machines, primary infected machines, and secondary infected machines, and to determine the ability of the primary and secondary infected pods to alter the configuration of the network.

3. The computer system of claim 1 further includes a resource component that determines the total resource capacity that the respective infection containers associated with the primary infection pod and the secondary infection pod are capable of consuming, in order to generate a total risk capacity metric.

4. The computer system of claim 3 further includes a licensing component that determines a license associated with the corresponding infection container.

5. The computer system according to claim 3, wherein, The resource component assessment evaluates the limited capacity of at least one of the processor, memory, or disk.

6. The computer system of claim 5, wherein the risk component dynamically generates a second contextual risk score and a second absolute risk score associated with the primary infected pod and the secondary infected pod based on one or more changes.

7. The computer system according to claim 1, wherein, The risk component employs a trained model to dynamically generate contextual risk scores and absolute risk scores associated with the primary infected pod and the secondary infected pod.

8. A computer-implemented method, comprising: The processor is used to examine a set of container images associated with each pod; The processor is used to identify a first subset of the pods containing the vulnerabilities; The processor is used to classify a first subset of the pods as primary infected pods; The processor is used to generate a first list of namespaces in which the primary infection pods are deployed within the network; The processor is used to examine network policies associated with a first list of namespaces to identify secondary suspicious pods capable of communicating with the primary infected pod. The processor is used to generate a list of secondary suspicious namespaces in which secondary suspicious pods are deployed within the network; The processor identifies one or more secondary suspicious pods that communicate with one or more primary infected pods. The processor generates a list of secondary infected pods based on one or more secondary suspicious pods that communicate with one or more primary infected pods; as well as The processor is used to generate contextual risk scores and absolute risk scores associated with primary and secondary infected pods. The context risk score is generated based on a measurement of at least one of the following: the number of primary infected pods, the number of secondary infected pods, the number of secondary suspicious pods, the number of primary infected namespaces, the number of secondary infected namespaces, the number of secondary suspicious namespaces, the number of primary infected machines, the number of secondary infected machines, the number of suspicious machines, the total risk capacity metric, and the permission level on the API server. The absolute risk score is generated based on the context risk score and the common vulnerability and exposure CVE scores corresponding to the vulnerability.

9. The method according to claim 8, further comprising: The processor is used to examine the specifications and privileges associated with the primary and secondary infected pods; The processor is used to generate a list of suspicious machines, primary infected machines, and secondary infected machines; and The processor is used to determine the ability of primary and secondary infection pods to modify the network configuration.

10. The method of claim 8, further comprising using the processor to determine the total resource capacity that the respective infection containers associated with the primary infection pod and the secondary infection pod can consume, and using the processor to generate a total risk capacity metric.

11. The method of claim 10, further comprising using the processor to determine a license associated with the corresponding infection container.

12. The method of claim 10, further comprising using the processor to evaluate the limited capacity of at least one of the processor, memory, or disk.

13. The method of claim 12, further comprising using the processor to generate a second contextual risk score and a second absolute risk score associated with the primary infected pod and the secondary infected pod based on one or more changes.

14. A computer program product comprising program instructions executable by a processor to cause the processor to: Examine a set of container images associated with the pod; Identify the first subset of pods containing the vulnerability; Classify the first subset of pods as primary infected pods; Generate a first list of the namespaces within the network in which the primary infection pods are deployed; Examine the network policies associated with the first list of namespaces to identify secondary suspicious pods that can communicate with the primary infected pod; Generate a list of secondary suspicious namespaces in which the secondary suspicious pods are deployed within the network; Identify one or more secondary suspicious pods that communicate with one or more primary infected pods; A list of secondary infected pods is generated based on one or more secondary suspected pods that have communicated with one or more primary infected pods; and The processor is used to generate contextual risk scores and absolute risk scores associated with primary and secondary infected pods. The context risk score is generated based on a measurement of at least one of the following: the number of primary infected pods, the number of secondary infected pods, the number of secondary suspicious pods, the number of primary infected namespaces, the number of secondary infected namespaces, the number of secondary suspicious namespaces, the number of primary infected machines, the number of secondary infected machines, the number of suspicious machines, the total risk capacity metric, and the permission level on the API server. The absolute risk score is generated based on the context risk score and the common vulnerability and exposure CVE scores corresponding to the vulnerability.

15. The computer program product of claim 14, wherein the program instructions may also be executed by the processor to cause the processor to: Examine the norms and privileges related to primary and secondary infected pods; Generate a list of suspicious machines, primary infected machines, and secondary infected machines; and Determine the ability of primary and secondary infection pods to alter the network configuration.

16. The computer program product of claim 14, wherein the program instructions may also be executed by the processor to cause the processor to determine the total resource capacity that the respective infection containers associated with the primary infection pod and the secondary infection pod can consume, and to generate a total risk capacity metric.

17. The computer program product of claim 16, wherein the program instructions may also be executed by the processor to cause the processor to determine a license associated with the corresponding infection container.

18. The computer program product of claim 14, wherein the program instructions may also be executed by the processor to cause the processor to generate a second context risk score and a second absolute risk score associated with the primary infected pod and the secondary infected pod based on one or more changes.

Images