1. Home
    2. Prisma
    3. Prisma Cloud
    4. Prisma Cloud Compute Edition Administrator’s Guide
    5. Vulnerability management
    6. Troubleshoot vulnerability detection
    End-of-Life (EoL)

    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
      Manage > System > View Logs > Upload / Download Debug logs
      . You can also use twistcli to upload logs:
      $ ./linux/twistcli support upload --help
      1. The debug log option is only available on self-hosted Consoles. In the event that you have a SaaS Console, gather the console.log (from
        Manage > System > View Logs
        ) and the defender.log (under /var/lib/twistlock/log directory on host) from the host where the image was first scanned.
    2. Image details
      : If the issue is in a container image, provide the affected container image (image.tar). You may also check if the image can be downloaded from Docker Hub and share a link to pull the image. Always validate the Image ID SHA to ensure it’s the same image. If you are unable to share the image, please provide an image where the issue reproduces that we can analyse.
    3. Scan discrepancy report sheet
      : Ensure you have a spreadsheet with following columns info filled out from your prior analysis.
      CVE ID
      Package Type
      Package Name
      Package Version
      Path where package is found in image
      CVE Reported in Console? Yes/No
      CVE Reported by any other vendor/source?
      Your explanation/comments
      Example: CVE-2021-38297
      OS
      gnutls28
      3.6.7-4+deb10u5
      /usr/bin/gnutls
      Yes. Suspect it to be a false positive
      I don’t believe this CVE should be reported for this version of package because I don’t see version in NVD.

    Frequently Asked Questions

    I see a CVE in the scan, but it does not appear on NVD or is still under analysis. What is the information I’m seeing?

    When a CVE is assigned to a vulnerability, usually NVD analysis takes place, and it may take multiple days for the NVD site to update with description and the affected releases range. Instead of waiting for the official analysis to complete, our researchers manually review the details of the CVE and add it as a pre-filled CVE to our Intelligence Stream, so you can know you are vulnerable and mitigate the vulnerability before the official analysis is done. See the