> For the complete documentation index, see [llms.txt](https://docs.prismacloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.prismacloud.io/content-collections/runtime-security/vulnerability-management/vulnerability-explorer.md).
# 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 help you answer two questions:
*1. How many CVEs do you have?*
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
The CVE statistics listed in the Vulnerability Explorer are per CVE-ID and not a total count of all CVEs under all resources.
*2. How many images do you need to fix?*
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 - 1
* Low - 1
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 a total number of vulnerabilities.
## Filter tool
The filter tool at the top of the page allows you to search for a CVE ID to determine if any image, function, or host in your environment is impacted by a specific vulnerability (whether it is in the critical vulnerabilities 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 is listed in the detailed information dialog when you click on a row in the top ten tables.
Consider the following guidelines:
* The data for each CVE ID that consists of the 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, filtering 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 percentage of the impacted resources 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 for when the container image was first scanned.
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 Runtime Security > Manage > System > Scan > Scan settings > Running images**, when the option **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](https://www.cisa.gov/known-exploited-vulnerabilities-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.
* **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 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
```
### Supported Packages
The Vulnerability Explorer lists the packages where CVEs are detected during runtime tabulated here.
| Language | Host | Container | App-embedded | Serverless |
| -------- | ---- | --------- | ------------ | ---------- |
| C# | X | X | X | X |
| Go | X | X | X | X |
| Node.js | X | V | X | X |
| Ruby | X | V | X | X |
| Java | X | V | X | X |
| Python | X | V | X | X |
Legend:
X: Supported V: Supported with specific considerations or variations
\+ For more details, see [scan reports](/content-collections/runtime-security/vulnerability-management/scan-reports.md).
## 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 latest data by clicking the **Refresh** button in the top right of Vulnerability Explorer. You must rescan each resource such as deployed images, registries, hosts, and functions before a refresh. The **Refresh** button has a red marker when new data is available to be crunched.
The Vulnerability Explorer can not be refreshed when filters are applied. To continue with the **Refresh** option, you need to remove the filters.
## Enhanced RHEL Vulnerability Reporting in Prisma Cloud
To improve accuracy in vulnerability detection, Prisma Cloud now includes RPM module and stream information for Red Hat Enterprise Linux (RHEL) images in the vulnerability reports. This enhancement ensures that all RPM packages installed by a module are properly examined during scans, reducing false positives and improving detection reliability.
### Understanding RPM Modules and Streams
In Red Hat Enterprise Linux (RHEL), an RPM module is a collection of related RPM packages that represent a software component, including an application, its dependencies, and supporting utilities.
### Module Structure
* **Module Streams:** Virtual repositories within the AppStream repository, each representing a specific version of the module with independent updates.
* **Stream Activation:** Only one stream of a module can be active at a time, meaning only one version of a component can be installed on a system.
### Example Notation
```plaintext
python39:3.9/python39
```
* **Module:** `python39`
* **Stream:** `3.9`
* **Source Package:** `python39`
### Benefits of Module-Aware Vulnerability Reporting
**Improved Accuracy:** CVE fixes are matched to the correct module stream, reducing incorrect vulnerability detection.
**Reduced False Positives:** Vulnerabilities fixed in older streams are no longer misreported.
**Comprehensive Coverage:** All RPM packages installed by a module are linked to their respective vulnerabilities.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.prismacloud.io/content-collections/runtime-security/vulnerability-management/vulnerability-explorer.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.