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
.

Roll-ups

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.

Filter tool

The filter tool at the top of the page allows you to search for a CVE ID in order to determine if any image, function, or host in your environment is impacted by a specific vulnerability (whether it is in the critical vulnerabilties list or not).
The filter tool also allows you to filter vulnerabilities based on CVSS threshold, Severity threshold, or Collections in your environment. For example, the CVE matches the filter if its highest severity is equal to or higher than the severity specified.

Vulnerabilities (CVE) results

Vulnerability Explorer gives you a ranked list of the most critical vulnerabilities in your environment based on the risk score. The ranked list consists of CVEs that are affecting the environment. Each CVE includes data about its risk factors, severity, CVSS, impacted packages, and impacted resources.
There are separate top ten lists for the container images, registry images, hosts, and functions in your environment.
You can export the full list of CVEs affecting your environment in a CSV format. You can also download a detailed CSV report on impacted resources for a CVE ID from the
Actions
column.
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 Highest risk factor columns.
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.
Consider the following guidelines:
  • The data for each CVE ID that consists of highest risk score, highest CVE risk factors, highest environmental risk factors, highest severity, and highest CVSS for all impacted packages display the highest value for the CVE based on your entire environment. This is irrespective of the applied filters, collections, or accounts that you are assigned to.
  • The vulnerability (CVE) results hide the
    impacted resources
    if you use a filter or have an assigned collection or account as the percentage refers to the entire environment. This is supported for the System Admin role only.
  • The exported CSV displays an empty column of
    impacted resources
    if you use a filter or have an assigned collection or account as this percentage refers to the entire environment.
  • If a filter returns more than 100 results, only the top 100 results are shown. You can download the full data in a CSV format.
  • You cannot combine the filters
    CVSS threshold
    and
    Severity threshold
    with
    Collections
    . Also, filter by
    CVSS threshold
    and
    Severity threshold
    is not supported for users with assigned collections or accounts.
  • The vulnerability (CVE) results display vulnerabilities based on a set filter threshold or higher.

CVE ID details

The vulnerability explorer CVE dialog appears when you click on a row in the Vulnerabilities (CVE) results.
The vulnerability explorer CVE dialog displays the following:
  • CVE description and its impacted packages.
  • A list of all impacted resources such as deployed images, registry images, hosts, and functions filtered based on the severity threshold, CVSS threshold, or collections if specified in the
    Filter tool
    of the vulnerability explorer.
  • The highest risk profile for a CVE ID based on the highest risk in an environment.
    For each resource type, the highest risk profile includes the risk score and risk factors found in the entire environment and is regardless of the filters and assigned collections or accounts.
In the risk profile section, you can see the impacted resources percentage along with the risk score.
+ The
impacted resources percentage
is not displayed if you use a filter or have assigned collections or accounts as it reflects the value based on the entire environment.
You can export a list of impacted resources in a CSV format from here or from the
Actions
column as described earlier.
For each impacted resource, you can hover over the
Vulnerability
tag next to the resource name to see the specific package, severity, and CVSS of the CVE for a resource.

Image details

The image details also show the Start time when the image was first deployed within the container.
Also, you can see the time duration that has elapsed since the deployment. This helps in determining how long a vulnerable image has been running.
In
Prisma Cloud Compute > Manage > System > Scan > Scan settings > Running images
, when the Only scan images with running containers is turned off, the image details show the Start time when the Defender first reads the image. This is applicable for all images (deployed and not deployed).

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
Vulnerabilities
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 {High/Low}
     — Component is vulnerable to denial of service attacks, such as buffer overflow attacks, and ICMP floods. The risk is categorized as high or low based on impact.
  • Recent vulnerability
     — Vulnerability was reported in the current or previous year.
  • Exploit PoC
     — Code and procedures to exploit the vulnerability are publicly available.
  • Exploit in the wild
     — Exploit attempts of this vulnerability that have been seen in the wild. All vulnerabilities are from the CISA KEV Catalog.
  • 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 CNNS 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.
  • Sensitive information
     — Vulnerability exists in a container or a serverless function that stores private keys or has environment variables that provide sensitive information.
  • Root Mount
     — Vulnerability exists in a container with access to the host filesystem.
  • Runtime socket
     — Vulnerability exists in a container with access to the host container runtime socket.
  • Host Access
     — Vulnerability exists in a container with access to the host namespace, network, or devices.
  • Package in use
     — Vulnerability exists in a component that is actually running. For example, if Redis is running in a containe