Prisma Cloud Compute: Vulnerability appears under an incorrect layer in the Layers view.

• Vulnerabilities are detected under Monitor → Vulnerabilities → Deployed Images, confirming that the affected software exists in the running container filesystem.

• One or more vulnerabilities are classified as Application / Unmanaged components rather than operating system packages.

• The affected vulnerabilities are not associated with the Dockerfile layers that appear to build or install the application when viewed in the Layers tab.

• Vulnerabilities may appear attached to an unrelated Dockerfile instruction (for example, a base system package installation such as apk add ca-certificates) even though that instruction did not introduce the vulnerable software. For example:
  
  

  • 

• In some cases, vulnerabilities appear without any layer association, while still being reported in the vulnerability list. Just like the below screenshot:

• 
• Customers may observe inconsistent or confusing layer attribution, leading to uncertainty about which Dockerfile step introduced the vulnerability.

• Prisma Cloud Compute Self-Hosted
• Prisma Cloud Compute SaaS

The screenshot below shows the vulnerability CVE-2025-46817 being attached to the layer below.

RUN /bin/sh -c apk --no-cache add --no-check-certificate ca-certificates # buildkit

The layer above is a stable, non-empty OS package installation layer, and that’s exactly why Prisma often uses it as the “anchor” for vulnerabilities that can’t be tied to a precise build step. Because it creates real, persistent file changes, Docker/OCI records it as a non-empty diff layer (typically visible in docker history with a non-zero size and in inspect history as empty_layer=false).

Prisma uses a fallback heuristic and anchors the finding to an early, stable, non-empty layer from the image history. The association of a vulnerability with this layer is not a statement about where the software was installed. Instead, it reflects a best-effort estimation used when precise layer ownership cannot be determined. 

The vulnerability below is shown without a layer association:

In the above case, vulnerabilities are detected in the final runtime filesystem but are not associated with any Dockerfile layer. This occurs when the heuristic used to estimate layer ownership cannot identify a reliable reference point in the image metadata.

Layer association relies on correlating file metadata (such as modification time) with layer creation metadata recorded in the image history. If this metadata is missing, inconsistent, or invalid, the heuristic cannot confidently determine which layer likely introduced the affected files.

We understand why relying on Layer IDs or directly inspecting layer contents appears to be the most robust approach for mapping files and vulnerabilities back to their originating layers. However, there are important technical constraints and performance trade-offs that influence the current implementation.

While Layer IDs uniquely identify layers in an image manifest, they do not contain an index of the files within those layers. A container image is effectively a stack of compressed tar archives. To definitively determine that a specific file originated from a particular layer, the scanner would need to download, extract, and inspect every individual layer archive. This form of deep layer inspection is significantly more resource-intensive, requiring substantially higher CPU, memory, and I/O, and would negatively impact scan performance and scalability.

To maintain fast and efficient scanning, the current implementation relies on a metadata-based heuristic approach rather than full content extraction. Specifically, the scanner compares the file modification time (mtime) observed in the final filesystem with the layer creation time recorded in the image history. The assumption is that if a file was created or modified around time T, it most likely originated from the layer that was created at approximately the same time. This approach provides a reasonable balance between accuracy and performance for the majority of images.

Precise layer attribution for application-level vulnerabilities requires deep layer inspection, which is currently a product enhancement; customers who require this capability are encouraged to submit an RFE.