Troubleshoot vulnerability detection

Prisma Cloud offers a comprehensive Intelligence Stream for vulnerability management that draws on threat intelligence from commercial providers, the open source community, as well as distinctive vulnerability intelligence curated by Prisma Cloud vulnerability researchers.
Use this troubleshooting section to verify the accuracy of Prisma Cloud scan results, understand the logic behind scan reports, and provide the details requested in the template when you submit a support request for further analysis.
The information in this section will help answer the most common questions related to CVE scan reports –
  1. Whether a CVE reported by Prisma Cloud is suspected to be a false positive (meaning there is an assumption that the CVE doesn’t exist on a package / image but it displays on the Prisma Cloud Console)
  2. Whether a CVE in Prisma Cloud is suspected to be a false negative (meaning there is an assumption that a CVE does exist on package / image but it does not display on Prisma Cloud Console)

Prerequisites

Before you start with the troubleshooting workflow, check the following prerequisites for accurate scan results.
  1. Ensure you are running the latest version of Prisma Cloud Compute Console.
  2. Ensure you are running a supported version of Prisma Cloud Compute Defenders. Prisma Cloud Defender version is backward compatible for up to two major releases of Console.
  3. Ensure that the image or OS is supported.
    1. If the problem is in a container, ensure that the image is based on a supported OS.
    2. If the problem is in a host, ensure it is running a supported OS.
  4. Connection to Intelligence Stream is up to date.
    1. Navigate to
      Manage > System > Intelligence
      .
    2. Verify that the
      status
      is
      Connected
      .

Troubleshooting Steps

After you complete the prerequisite checks, continue to troubleshoot further. The commands below are for Linux distributions but you can use the same process for Windows distributions.

Step 1: Running the image in a container

Whether troubleshooting for a false positive or a false negative scenario, the image should be searched for signs of the given package or file that has been associated with the CVE. Running the image in a container is a good way to proceed. As a best security practice, always run these experiments in a sandbox environment instead of production.
Download the image or load it from a tar on a host protected by a container Defender environment:
docker pull <imagename> OR docker load -i <image.tar>
Instantiate a container from the image:
docker run –rm –detach –name vuln_testing <imagename>
If the image exits immediately, the entrypoint or CMD associated with it most likely doesn’t spawn a long running process. In that case, the docker run command given above can have a command and arguments appended to it overriding the built in directives and ensuring that the container remains up while it is being investigated. For example:
$ docker run –rm –detach –name vuln_testing <imagename> sleep infinity

Step 2: Investigate the Container

Get the ID of the running container then exec into it:
$ docker ps | grep vuln_testing $ docker exec -ti <containerID> /bin/bash
If the bash shell isn’t installed in the image, try alternate shells such as /bin/sh or /bin/ash.

Step 3: Find the Linux distribution of the image

Match the detected OS type in the Console against the listed OS inside running container to ensure that it was correctly identified.
$ cat /etc/os-release
Tip: If the os-release file is not found, look for /etc/redhat-release, /etc/lsb-release, or other files matching /etc/*-release.

Step 4: Locate the package associated with the CVE

Locate the package or file that is associated with the CVE that was listed, or that was not detected despite the expectations. Additionally, confirm the version of the package detected inside the container with the one shown in Prisma Cloud Console or, in case of false negative, which is shown in the other source confirming the CVE.
An easy command to do this is to use find the package in the whole filesystem is:
$ find / -name <package_name>
Example:
abc@3f61f8497e23:/# find / -name console /dev/console /sys/devices/virtual/tty/console /sys/class/tty/console
Run the package binary with --version tag if available. You can also search for the version in Console. Go to
Monitor > Vulnerabilities
, then click on an image, and select the
Package Info
tab.
Example:
abc@3f61f8497e23:/# /usr/bin/wget --version GNU Wget 1.20.3 built on linux-gnu.
Some other ways to find the package, depending on the type of package are -
Package Type
Command
jar
find / -iname '*.jar' | grep <jar_name>
Get the version from the jar name.
Example output:
/opt/amq/webapps/hawtio/WEB-INF/lib/httpcore-4.4.4.jar
Npm/node packages
npm list | grep -i <package_name>
sh-4.2$ cd <path> sh-4.2$ cat package.json | grep -i version
If investigating false positives, find the package path from image details in Console. Select
Monitor > Vulnerabilities > Images
, click on the image, and select the
Package Info
tab.
OS
For OS packages, use the OS package manager to find the installed package and version.
For example, you can use the following for RHEL/CentOS/SUSE packages (here searching for the curl package):
Another example for Debian/Ubuntu:
python
For python packages, you can run the following command in the package path (if already known)
$ cat __init__.py | grep -i __version__
(OR) in the .dist-info directory.
$ cat METADATA | grep -i version

Analyzing Results

The above steps should help answer whether the vulnerable package exists in the image or not and answer if a CVE is truly false positive. If you found the package and the vulnerable version in image but have questions on the report’s accuracy, you can search the vendor’s official feeds to confirm the source of the CVE report.

1. "I found the package but I’m not sure if it’s truly vulnerable."

Navigate to
Monitor > Vulnerabilities > CVE Viewer
, type the CVE ID and verify the source matching OS of your image, or look for the reference with empty Distro and Release if it’s a specific language library.
You can then directly search vendor feeds to confirm CVE’s authenticity. For OS packages, the relevant vendor site should be consulted. For specific language libraries, the site of that project should be visited. The National Vulnerability Database (NVD) should be used for locating CVE information that is not available on official vendor feeds.
Vendor vulnerability data may differ between feeds and NVD analysis. For example, in severity, description or affected versions. Prisma Cloud gives more weight to specific vendor analysis to provide accurate vulnerability data.
Example 1: A vulnerability was determined to be high severity per NVD analysis, but Red Hat Linux analysis determined the vulnerability to be of high severity on RHEL releases. Prisma Cloud should display high severity in this case.
Example 2: A vulnerability was discovered in an open-source package and was fixed in the latest release. NVD analysis mentioned the vulnerability affects all releases earlier than the latest release. At the same time, the vulnerability could be fixed on earlier releases on RHEL, with maintainers having backported the patch to earlier releases of the package for RHEL.

2. "I found the vulnerable package but Prisma Cloud doesn’t show it’s CVE."

When looking into a false negative, it is important to confirm the type of the vulnerability (that is anticipated to be ‘missing’ from scan results), where type equals one of the supported formats that Compute currently detects when interrogating an image.
Supported types:
  • package - an OS package, such as an RPM (Red Hat and derived distributions), dpkg/deb (Debian and derived distributions), or apk (Alpine Linux).
  • jar - the Java Archive format, which is a zip file with a standard structure. The war file format, or web app archive, is also supported.
  • python - a Python library, sometimes consisting of zip archives with varying structures and names (eggs, wheels) or plain text files on disk with supporting metadata text files.
  • nodejs - a NodeJS library, primarily consisting of text files on disk with supporting metadata text files.
  • gem - a Ruby library, consisting of text files on disk with supporting metadata text files.
  • go - a Golang binary, which typically contains dependencies that are statically compiled into it. Where most C programs make use of dynamically linked libraries/shared-objects that are present on the host and pulled in at run time, Golang binaries usually have their dependencies embedded within them at compile time.
  • app - a binary associated with a well known application, such as Nginx or PostgreSQL.
If it is one of the above supported types yet missing in Prisma Cloud Compute’s scan report, then open a support case and provide the following information so our teams can investigate further.

Submit a Support Request

When submitting a technical support request with Palo Alto Networks, provide the following information to help our teams identify the root cause more quickly. This information is required to review escalations.
  1. Debug logs: Provide full debug logs through