1. Overview

The 'dependencies' and 'devDependencies' sections from package.json file may contain special metadata chars (~ and ^), which are picked up by Prisma Cloud as part of the package version, causing these false positives. If using twistcli, these fields are evaluated when the —include-js-dependencies flag is set. These are also evaluated for images when the "Scan for vulnerable javascript package dependencies within images and functions" is toggled on. This toggle can be found on the Manage > System > Scan Page

We need to actually find which version of the package is installed on the disk. The scan works as expected when the dependencies are installed on the disk, or package.json contains specific versions.

If the package is not installed on the disk, Prisma Cloud can’t really tell which version was installed when ~ or ^ is prepended to the version.

clearing cache dependencies.1

2. Error messages

  • With "Scan for vulnerable javascript package dependencies within images and functions" toggled off you are still seeing vulnerabilities found in the javascript package dependencies in image scans.

  • When using twistcli for scanning and the "—include-js-dependencies flag is set, you may also see false positives.

3. Steps to confirm the issue

Toggle "Scan for vulnerable javascript package dependencies within images and functions" on and off and compare image scans within Prisma Cloud. The vulnerability report for the images in question will remain the same.

4. Troubleshooting steps

First, ensure that the "scan JS dependencies" option found at Manage > System > Scan is disabled.

For each of the images experiencing the nodejs false positives, you will need to remove any entries for them in the local cache of the Defenders as well as the Mongo DB instance on the Console.

Each image will be identified by the hash that function as the unique identifier in Prisma Cloud.

For Example: sha256:c8c1e1051a30b0303669a6edd4a666f8c3a73d0554c83e93285c9ca28cb744a0

On each host where a Defender is running, the image cache will be found in a file under /var/lib/twistlock/local_db/local/[ version ]/images, where "[ version ]" is the TL version that you’re running. That directory contains files that are named using the hash ID of each cached image.

For Example: /var/lib/twistlock/local_db/local/19.03.317/images/sha256:c8c1e1051a30b0303669a6edd4a666f8c3a73d0554c83e93285c9ca28cb744a0

Once the local Defender caches have been cleared, you’ll need to exec into your Console container

$ docker exec -it twistlock_console sh" or "kubectl -n twistlock exec -it twistlock-console-xxxx sh"

Open up a Mongo DB session using the following command:

$ mongo \
  --ssl --sslAllowInvalidHostnames \
  --sslCAFile /var/lib/twistlock/certificates/ca.pem \
  --sslPEMKeyFile /var/lib/twistlock/certificates/client.pem \
  --sslPEMKeyPassword `cat /var/lib/twistlock/certificates/service-parameter`

Select the Prisma Cloud DB
  > use twistlock

Then delete the record for each of the impacted images with:

  > db.images.remove({"_id":"[ image id ]"})

For Example:
  > db.images.remove({"_id": "sha256:c8c1e1051a30b0303669a6edd4a666f8c3a73d0554c83e93285c9ca28cb744a0"})
  WriteResult({ "nRemoved" : 1 })
  > quit

4.1. Additional information

In order for the new scan results to take effect, we need to delete the image from Defender cache and Console Mongo DB, then initiate a scan.

After removing cached results, we were able to see new scans take effect and no longer show any false positives but only those vulnerabilities which match packages that are installed.

5. Prisma Cloud version

6. Cautionary notes

  • When the local cache for a Defender is removed, all scans will also be removed from that Defender.