Scanning Procedure
Table of Contents
Prisma Cloud Enterprise Edition
Expand all | Collapse all
-
- Getting started
- System Requirements
- Cluster Context
-
- Defender Types
- Manage your Defenders
- Redeploy Defenders
- Uninstall Defenders
-
- Deploy Orchestrator Defenders on Amazon ECS
- Automatically Install Container Defender in a Cluster
- Deploy Prisma Cloud Defender from the GCP Marketplace
- Deploy Defenders as DaemonSets
- VMware Tanzu Application Service (TAS) Defender
- Deploy Defender on Google Kubernetes Engine (GKE)
- Google Kubernetes Engine (GKE) Autopilot
- Deploy Defender on OpenShift v4
- Deploy Defender with Declarative Object Management
-
- Agentless Scanning Modes
-
- Onboard AWS Accounts for Agentless Scanning
- Configure Agentless Scanning for AWS
- Onboard Azure Accounts for Agentless Scanning
- Configure Agentless Scanning for Azure
- Onboard GCP Accounts for Agentless Scanning
- Configure Agentless Scanning for GCP
- Onboard Oracle Cloud Infrastructure (OCI) Accounts for Agentless Scanning
- Configure Agentless Scanning for Oracle Cloud Infrastructure (OCI)
- Agentless Scanning Results
-
- Rule ordering and pattern matching
- Backup and Restore
- Custom feeds
- Configuring Prisma Cloud proxy settings
- Prisma Cloud Compute certificates
- Configure scanning
- User certificate validity period
- Enable HTTP access to Console
- Set different paths for Defender and Console (with DaemonSets)
- Authenticate to Console with Certificates
- Customize terminal output
- Collections
- Tags
- WildFire Settings
- Log Scrubbing
- Permissions by feature
-
- Prisma Cloud Vulnerability Feed
- Scanning Procedure
- Vulnerability Management Policies
- Vulnerability Scan Reports
- Scan Images for Custom Vulnerabilities
- Base images
- Vulnerability Explorer
- CVSS scoring
- CVE Viewer
-
- Configure Registry Scans
- Scan Images in Alibaba Cloud Container Registry
- Scan Images in Amazon Elastic Container Registry (ECR)
- Scan images in Azure Container Registry (ACR)
- Scan Images in Docker Registry v2 (including Docker Hub)
- Scan Images in GitLab Container Registry
- Scan images in Google Artifact Registry
- Scan Images in Google Container Registry (GCR)
- Scan Images in Harbor Registry
- Scan Images in IBM Cloud Container Registry
- Scan Images in JFrog Artifactory Docker Registry
- Scan Images in Sonatype Nexus Registry
- Scan images in OpenShift integrated Docker registry
- Scan Images in CoreOS Quay Registry
- Trigger Registry Scans with Webhooks
- Configure VM image scanning
- Configure code repository scanning
- Malware scanning
- Windows container image scanning
- Serverless Functions Scanning
- VMware Tanzu Blobstore Scanning
- Scan App-Embedded workloads
- Troubleshoot Vulnerability Detection
-
- Compliance Explorer
- Enforce compliance checks
- CIS Benchmarks
- Prisma Cloud Labs compliance checks
- Malware Scanning
- Serverless functions compliance checks
- Windows compliance checks
- DISA STIG compliance checks
- Custom compliance checks
- Trusted images
- Host scanning
- VM image scanning
- App-Embedded scanning
- Detect secrets
- OSS license management
-
- Alert Mechanism
- AWS Security Hub
- Cortex XDR alerts
- Cortex XSOAR alerts
- Email alerts
- Google Cloud Pub/Sub
- Google Cloud Security Command Center
- IBM Cloud Security Advisor
- JIRA Alerts
- PagerDuty alerts
- ServiceNow alerts for Security Incident Response
- ServiceNow alerts for Vulnerability Response
- Slack Alerts
- Splunk Alerts
- Webhook alerts
- API
Scanning Procedure
This article describes the vulnerability image scanning flow for deployed containers, registries, and CI.
The scanning flow is similar for both Docker and Dockerless images, except for a single difference, described in Scan reports for CRI environments.
Image scanning procedure
Prisma Cloud uses a variety of approaches that are purpose-built differently for detecting packages on images and hosts.
The Host Defender only scans applications, as well as language-based packages, if the processes are running.
The Windows Defender only scans packages that are installed with a package manager, missing Microsoft hotfixes, and .net framework applications.
The following diagram (Chart 1) shows the Defender scanning flow:

The following diagram (Chart 2) shows the twistcli scanning flow:

The steps in the scanning flow are:
- An image scanning request is initiated. This can be done by one of the following:
- Console - generates periodic scan requests (see Chart 1)
- Defender - when a new container starts (in this step we skip step 1 in Chart 1 since the Defender initiates the scan)
- twistcli - triggered manually or in the CI pipeline (see Chart 2)
- Defender harvests the image components versions to create the image manifest by scanning the image, and the Defender looks for:
- Component and version details from OS package managers.
- Executables (identified by magic signatures on the file system)notinstalled by the package manager:
- Selects the executables that are supported by Prisma Cloud.
- Identifies each executable’s version details from the binary metadata.
- Based on the information from step 2, Defender generates animage manifestand sends it to the Console.
- The Console identifies the vulnerabilities in each image by correlating the image manifest with the Intelligence Stream:
- The intelligence CVE stream is composed of per-distro CVEs (such as Red Hat and Ubuntu), un-packaged software CVEs (see supported packages and languages), and various open-source library CVEs (such as Node.js and python). The Console is continually updated by the Intelligence Stream to provide the most up-to-date results.The following table lists the manifest files known to the scanner.
Package manager | File name |
---|---|
Go | go.sum |
Java (Gradle) | build.gradle, build.gradle.kts, gradle.properties |
Java (Maven) | pom.xml |
JavaScript (NPM) | package.json, package-lock.json, npm-shrinkwrap.json, bower.json |
Python (pip) | req*.txt |
- The correlation results are calculated, stored in a database, and displayed in the Console UI.
The Console manages the current scan state and distributes the work to Defenders.
Scan reports for CRI environments
Deployed images
— The scanning logic is the same for Dockers and Dockerless environments,
the only difference lies in the scanned object.
In Docker environments, Prisma Cloud scans images by running the image with Defender as the entrypoint.
Dockerless doesn’t support this method, so for Dockerless environments, Prisma Cloud scans the running container.
As a result, when scanning deployed images in Dockerless environments, the Defender detects the packages added to a running container only when the packages are added before the initial scan.The Console stores the CI image scan and registry scan results. An image previously scanned as a registry image will not be re-scanned by the Defender at the runtime.
Registry scan
— The scanning logic is the same for Docker and Dockerless environments
Any Container Defender running on a host with the Docker Engine container runtime or container runtime interface (CRI) can scan a registry.
Learn more about registry scanning.When a scan result for an image with a certain SHA-ID exists, the Console checks if there is a version of the Defender that is newer than the one that scanned the image. If there is a newer Defender available, then the Console sends a scan request to the Defender to re-scan the image with the same SHA-ID, if not this image is not re-scanned.
Twistcli scans
— Scans conducted by twistcli are similar for Docker and Dockless (CRI).
In both environments, twistcli scans run from outside the container image.
For Dockerless environments, Podman must be installed on the host, to allow scans to run from outside the container image. Learn more in the twistcli scan images document.