> 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/admin-guide/33/vulnerability-management/scan-reports.md). # View Vulnerability Scan Reports Prisma Cloud scans images, hosts, and functions to detect vulnerabilities. The Prisma Cloud Intelligence Stream keeps the Console up to date with the latest vulnerabilities. The data in this feed is used for agentless scanning and is also distributed to your Defenders for scanning purposes. The initial scan is triggered when a Defender is installed, or when you enable agentless scanning, the scans check for: * Published Common Vulnerabilities and Exposures (CVEs) * Vulnerabilities from misconfigurations * Malware * Zero-day vulnerabilities * Compliance issues * Secrets After the initial scan, subsequent scans are triggered: * Periodically, according to the [scan interval](/admin-guide/33/configure/configure-scan-intervals.md) configured in the Console. By default, images are scanned every 24 hours. * When new images are deployed onto the host. * When scans are forced with the **Scan** button in the Console. Through the Console, Defender can be extended to scan images for custom components. For example, you can configure Defender to scan an internally developed library named `libexample.so`, and set a policy to block a container from running if `libexample.so` version `1.9.9` or earlier is installed. For more information, see Scanning custom components. ## View Image Scan Reports Review the health of all images in your environment. Sorting the table on vulnerability severity based on data from the last scan. If you update your vulnerability policy with a different alert threshold, rescan your images if you want to be able to sort based on your new settings. 1. Open the Console, then go to **Monitor > Vulnerabilities > Images**. The table summarizes the state of each image in your environment. All vulnerabilities identified in the last image scan can be exported to a CSV file by clicking the **CSV** button in the top left of the page. In case multiple images share the same image ID, but with different tags on different hosts, then these will be shown using +\ in the Tag column, as can be seen in the screenshot below.

image scan reports summary with multiple tags

2. Click on an image report to open a detailed report. 3. Click on the **Vulnerabilities** tab to see all CVE issues. CVE vulnerabilities are accompanied by a brief description. Click **Show details** for more information, including a link to the report on the National Vulnerability Database. The **Fix Status** column contains terms such as 'deferred', 'fixed in…', and 'open'. These strings are imported directly from the vendors' CVE databases. They are not Prisma Cloud-specific. For more information on the Risk Factor details, visit [CVSS Scoring](/admin-guide/33/vulnerability-management/cvss-scoring.md).

## Tagging Vulnerabilities To help you manage and fix the vulnerabilities in your environment, you can assign tags to each vulnerability. The list of available tags is defined under **Manage > Collections and Tags > Tags > Tag definition** (see [Tag definition](/admin-guide/33/configure/tags.md)). To assign a tag to a vulnerability, click on the **Add Tags to CVE** action in the **Tags** column. Tagging a vulnerability will apply by default to the CVE ID, package, and resource you assigned the tag from. You can granularly adjust and extend the tag scope under **Manage > Collections and Tags > Tags > Tag assignment** (see [Tag assignment](/admin-guide/33/configure/tags.md)). For example, assigning a tag from the following scan report will apply to *CVE-2020-16156*, package *perl*, and image *ubuntu:20.04*.

You can also add comments to each tag assignment, for example, to explain the reason this tag was added. Do it by clicking the comment icon on the left side of the tag. By default, all vulnerabilities, according to your policy, are listed. However, you can also examine vulnerabilities only with specific tags. Use the drop-down list to filter by tags.

Remove a tag from a vulnerability using the close action available on the tag. When removing a tag from the scan report, the entire tag assignment is removed, which may be wider than just the single place you remove it from. For example, removing a tag that is applied to image *ubuntu:20.04* by a tag assignment defined for images *ubuntu:\**, will remove the entire tag assignment, which means the tag will be removed from all *ubuntu* images. For more granular tag removal, go to the **Manage > Collections and Tags > Tags > Tag assignment**, and adjust the relevant tag scope. ## Per-layer Vulnerability Analysis To make it easier to understand how images are constructed and what components have vulnerabilities, Prisma Cloud correlates vulnerabilities to layers. This tool helps you assess how vulnerabilities were introduced into an image, and pick a starting point for remediation. To see the layer analysis, click on an image to open the scan report, then click the **Layers** tab.

There are differences in the scan results between an image created by a Dockerfile and an image pulled by a registry. This is because the times in the image created by Dockerfile are more accurate. Therefore the vulnerability scan results from the Dockerfile are more accurate. ### RHEL Images The Prisma Cloud layers tool shows the instructions used to create each layer in an image. RHEL images, however, don’t contain the necessary metadata, so the Prisma Cloud layers tool shows an empty black box.

To validate that the required metadata is absent, run *docker history IMAGE-ID* on a non-RHEL image. The *CREATED BY* column is fully populated.

image scan reports docker history normal

Next, run *docker history IMAGE-ID* on an RHEL image. Notice that the *CREATED BY* column is empty.

## Packages Information Prisma Cloud uses risk scores to calculate the severity of vulnerabilities in your environment. Scan reports have a **Package info** tab, which lists all the packages installed in an image or host. It also shows all active packages, which are packages used by running software. To see these active packages, open a scan report, open the **Package info** tab, and look at the **Binaries** column (see the **App** column in host scan reports). This column shows what’s actually running in the container. For example, the fluent/fluentd:latest container in the following screenshot runs */usr/bin/ruby*. One of the packages utilized by the Ruby runtime is the bigdecimal gem. If you were prioritizing mitigation work, and there was a severe vulnerability in bigdecimal, bigdecimal would be a good candidate to address first.

## Process Information Prisma Cloud scan reports provide visibility over the startup processes of the image. To see the image startup processes, open a scan report and go to the **Process info** tab. The processes list is created by a static analysis of the image, which first parses the image history to get the list of startup binaries. The algorithm then iterates over the image binaries and tries to find these startup binaries on the disk (in the file system). Those which were found are displayed under the **Process info** tab.

## Per-finding Timestamps The image scan reports of Prisma Cloud show the following per-vulnerability timestamps: * Age of the vulnerability based on the discovery date. This is the first date that the Prisma Cloud scanner found the vulnerability. * Age of the vulnerability based on its published date. This represents the date the vulnerability was announced to the world. Registry scan reports show the published date only.

Timestamps are per-image, per-vulnerability. For example, if CVE-2019-1234 was found in image foo/foo:3.1 last week and image bar/bar:7.8 is created from foo/foo:3.1 today, then the scan results for foo show the discovery date for CVE-2019-1234 to be last week and for bar it shows today. Timestamped findings are useful when you have time-based SLAs for remediating vulnerabilities (e.g. all critical CVEs must be fixed within 30 days). Per-finding timestamp data makes it possible to track compliance with these SLAs. ## Host and VM Image Scanning Prisma Cloud also scans your hosts and VM images for vulnerabilities. To see the scan report for your hosts and VM images, go to **Monitor > Vulnerabilities > Hosts**. By default, all vulnerable packages, according to your policy, are listed. However, you can also examine vulnerabilities specific to an app (systemd service). Use the drop-down list to select an app. Clear the selection to see all vulnerabilities for a host/VM image.

The **Package Info** tab lists all packages installed on the host/VM image. If a package has a component utilized by a running app, the affected running apps are listed in the **Apps** column. Prisma Cloud also collects and displays package license details. License information is available at all places where package details are displayed, such as **Monitor > Vulnerabilities > Images** (under the **Package Info** tab), **Monitor > Vulnerabilities > Hosts** and **Monitor > Vulnerabilities > Registry**, as well as the corresponding API endpoints.

Licensing compliance is supported only for viewing purposes and cannot be included in policies for alert/block capabilities. If a package path is missing in the scan results, it is usually because: * The package is integral to and managed by the operating system. For example, packages like `curl` and `tar` in Linux-based operating systems. * The scanner could not identify an installation directory containing both the gem name and version. Prisma Cloud runtime scanners extract gem information from `.gem` and `.gemspec` files. However, `.gemspec` files are typically located in standard Ruby directories that do not represent the actual installation path. The scanner infers the path only if it finds a directory containing both the gem name and version. If this pattern is not found, the path remains empty due to the inability to reliably determine the gem’s installed location. ## Scan Status The initial scan can take substantial time when you have a large number of images. Subsequent scans are much faster. To see the status of the image scans, go to **Monitor > Vulnerabilities > Images**. Each row in the table represents an image in your environment. If an image is being scanned, a progress bar shows the status of the scan. If there is no progress bar, the scan has been completed. ## Package Types Prisma Cloud uses compliance identification numbers to designate the package type when reporting vulnerabilities in images. Compliance IDs can be found in the CSV export files and API responses. To download image reports in CSV format, go to **Monitor > Vulnerabilities > Images**, and click the **CSV** button at the top of the table. For images, the **Type** and **Packages** fields report the package ID, package type, and package name respectively. For hosts, the **Type** and **Packages** fields report the package ID, CVE type, and package name respectively. The API output reports compliance IDs only.

The following table shows how compliance IDs map to package type. | Compliance ID number | Package type | | -------------------- | -------------------------------- | | 46 | Operating system/distro packages | | 47 | JAR files | | 48 | Gem files | | 49 | Node.js | | 410 | Python | | 411 | Binary | | 412 | Custom (set by customer) | | 415 | Nuget | | 416 | Go | --- # 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/admin-guide/33/vulnerability-management/scan-reports.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.