cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
132
Views
0
Helpful
0
Comments
jaredkalmus
Cisco Employee
Cisco Employee

Prisma Cloud has three different fields that identify images in their platform.

 

Image ID - Base image ID that can be duplicated for multiples images if they are built off the same original base image.

 

Digest ID - SHA that's guaranteed to be unique for each individual image based off the manifest of the image and its layers.

 

Base Image – This field maps to the Image that the child image was originally built on. This field is just a hyperlink in the Primsa UI that takes you to the base image. Cisco Vulnerability Management does not currently ingest this field.

 

Cisco Vulnerability Management currently only maps/ingest one of these fields, the Image ID field

PrismaUI.png

To put this into a real-life example, a user may have a container running with image ID abc123. They execute commands on that container to install a new software package. The user then wants to create a new container using the same image but with the new software package included. This new container would have the same Image ID (abc123) but a new Digest ID as a new layer was created to add the changes made to the base image.

This page may be helpful in understanding these terms and how they relate to one another: https://windsock.io/explaining-docker-image-ids/

If a new child image is spun up with new, unique vulnerabilities detected on any layer in the digest then those CVEs would be reported on the base image asset in Cisco Vulnerability Management (mapped to Image ID).

This deduplication ensures that asset owners do not suppress risk or inappropriately reset SLA due dates just because a new image was built off an existing known-bad image. However, this data merger could create confusion as the “found on” dates for vulnerabilities on an "old" image in Kenna could be very recent as the vulnerability wasn't reported until a new child image was spun off of the base image ID due to the base image being modified with a new layer.

Additionally, Prisma has a filter which suppresses base image vulnerabilities when viewing a child image, so vulnerabilities from the base image may not be shown to the user by default when viewing a child image, but they are displayed by default in the Cisco Vulnerability Management platform.

It is a security best practice to not use base images which are known to have high-risk vulnerabilities, and remediation actions should consist of removing any known-bad base images from repositories available to users so that new images are not created which contain vulnerabilities present within an existing base image.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: