End-of-Life (EoL)

Vulnerability Explorer

Most scanners find and list vulnerabilities, but Vulnerability Explorer takes it a step further by analyzing the data within the context of your environment. Because Prisma Cloud can see how the containers run in your environment, we can identify the biggest risks and prioritize them for remediation.
To view Vulnerability Explorer, open Console, then go to
Monitor > Vulnerabilities > Vulnerability Explorer


The charts at the top of the Vulnerability Explorer helps you answer two questions:
For each object type (image, host, function), the chart reports a count of vulnerabilities in each object class in your environment as a function of time. Consider an environment that has just a single image, where that image has three vulnerabilities: one high, one medium, and one low. Then at time=today on the
Images vulnerabilities
chart, you could read the following values:
    Critical - 0
    High - 1
    Medium - 1
    Low - 1
For each object type (image, host, function), the chart reports a count of the highest severity vulnerability in each object class in your environment as a function of time. Consider an environment that has just a single image, where that image has three vulnerabilities: one high, one medium, and one low. Then at time=today on the
Impacted images
chart, you could read the following values:
    Critical - 0
    High - 1
    Medium - 0
    Low - 0
Let’s look at it another way with a different set of data. Assume the reading at t=today reports the following values, where t is some point on the x-axis of the chart.
    Critical - 1
    High - 1
    Medium - 0
    Low - 2
If your policy calls for addressing all critical vulnerabilities, then the chart tells you that there is precisely one image in your environment that has at least one critical vulnerability. Therefore, your work for today is to fix one image. That image might also have two high vulnerabilities and twenty low vulnerabilities, which you will see when you open the image’s scan report, but this chart is not designed to give you a count of total number of vulnerabilities.

Search tool

The search tool at the top of the page lets you determine if any image or host in your environment is impacted by a specific vulnerability (whether it is in the top ten list or not).

Top ten lists

Vulnerability Explorer gives you a ranked list of the most critical vulnerabilities in your environment based on a scoring system. There are separate top ten lists for the container images, hosts, and functions in your environment.
The top ten table is driven by a risk score. The most important factor in the risk score is the vulnerability’s severity. But additional factors are taken into account, such as:
  • Is a fix available from the vendor?
  • Is the container exposed to the Internet?
  • Are ingress ports open?
  • Is the container privileged?
  • Is an exploit available?
The underlying goal of the risk score is to make it actionable (should you address the vulnerability, and with what urgency). Factors that contribute to the risk score are shown in the Risk Factors column.
Running containers can introduce additional environmental factors that increase the calculated score for a vulnerability. For example, when the container runs as root, it could exacerbate the problem. A list of container traits that heighten the risk are listed in the detailed information dialog when you click on a row in the top ten table.
The risk score and risk factors listed in the CVE details dialog are the ones of the image, host, or function with the highest risk score.

Risk factors

Risk factors are combined to determine a vulnerability’s risk score. Vulnerabilities with the highest risk scores are surfaced in the top ten lists.
Risk factors can also be used to prioritize individual vulnerabilities for mitigation. For example, if your cluster runs containers from disparate business groups, a major concern might be container breakouts. DoS vulnerabilities would likely be much less important than remote code execution vulnerabilities, particularly if exploit code were available, you were running as root, and you didn’t have AppArmor or SELinux applied.
To filter vulnerabilities based on risk factors: open the image, host, or function scan report; open the
tab; and select one or more risk factors.
Prisma Cloud supports the following risk factors:
  • {Critical | High | Medium} severity
     — Vulnerability severity.
  • Has fix
     — Fix is available from the distro, vendor, or package maintainer.
  • Remote execution
     — Vulnerability can be exploited to run arbitrary code.
  • DoS
     — Component is vulnerable to denial of service attacks, such as buffer overflow attacks, ICMP floods, and so on.
  • Recent vulnerability
     — Vulnerability was reported in the current or previous year.
  • Exploit exists
     — Code and procedures to exploit the vulnerability are publicly available.
  • Attack complexity: low
     — Vulnerability is easily exploited.
  • Attack vector: network
     — Vulnerability is remotely exploitable. The vulnerable component is bound to the network, and the attacker’s path is through the network.
  • Reachable from the internet
     — Vulnerability exists in a container exposed to the internet. The detection of this risk factor requires that CNNF will be enabled and network objects will be defined for external sources under
    Radar > Settings
    . Then, if a connection is established between the defined external source and the container, the container is identified as reachable from the internet.
  • Listening ports
     — Vulnerability exists in a container that is listening on network ports.
  • Container is running as root
     — Vulnerability exists in a container running with elevated privileges.
  • No mandatory security profile applied
     — Vulnerability exists in a container running with no security profile.
  • Running as privileged container
     — Vulnerability exists in a container running with --privileged flag.
  • Package in use
     — Vulnerability exists in a component that is actually running. For example, if Redis is running in a container or on a host as a service, then all the following (hypothetical) vulnerabilities could be surfaced by filtering on this risk factor:
    redis (main process) CVE-XXX, CVE-XXX |- libssl (dependent package) CVE-XXX, CVE-XXX |- libzip (dependent package) CVE-XXX, CVE-XXX

Risk trees

Risk trees lists all the images, namespaces, containers, and hosts that are vulnerable to a specific CVE. Risk trees are useful because they show you how you are exposed to a given vulnerability. Because Prisma Cloud already knows which vulnerabilities impact which packages, which packages are in which images, which containers are derived from which images, which containers run in which namespaces, and which hosts run which containers, we can show you the full scope of your exposure to a vulnerability across all objects in your environment.
For each top ten vulnerability, Prisma Cloud shows you a vulnerability risk tree. To see the vulnerability tree for a given CVE, click on the corresponding row in the top ten table to open a detailed CVE assessment dialog.
You can also generate a risk tree for any arbitrary CVE in your environment by entering the CVE ID into the search bar at the top of the page, then clicking on the result in the table to open a detailed CVE assessment dialog.

Recalculating statistics

Statistical data is calculated every 24 hours. You can force Console to recalculate the statistics for the current day with the current data by clicking the
button in the top left of Vulnerability Explorer. The
button has a red marker when new data is available to be crunched.