Scanning procedure
Table of Contents
Self.Hosted 22.06 (EoL)
Expand all | Collapse all
-
- Getting started
- System Requirements
- Prisma Cloud container images
- Onebox
- Kubernetes
- OpenShift v4
- Console on Fargate
- Amazon ECS
- Alibaba Cloud Container Service for Kubernetes (ACK)
- Azure Kubernetes Service (AKS)
- Amazon Elastic Kubernetes Service (EKS)
- Google Kubernetes Engine (GKE)
- Google Kubernetes Engine (GKE) Autopilot
- IBM Kubernetes Service (IKS)
- Windows
- Defender types
- Cluster Context
-
- Install a single Container Defender
- Automatically Install Container Defender in a Cluster
- App-Embedded Defender
- App-Embedded Defender for Fargate
- Default setting for App-Embedded Defender file system protection
- VMware Tanzu Application Service (TAS) Defender
- Serverless Defender
- Serverless Defender as a Lambda layer
- Auto-defend serverless functions
- Install a single Host Defender
- Auto-defend hosts
- Deploy Prisma Cloud Defender from the GCP Marketplace
- Decommission Defenders
- Redeploy Defenders
- Uninstall Defenders
-
- Rule ordering and pattern matching
- Backup and restore
- Custom feeds
- Configuring Prisma Cloud proxy settings
- Prisma Cloud Compute certificates
- Configure Agentless Scanning
- Agentless Scanning Modes
- 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
- Configure custom certs from a predefined directory
- Customize terminal output
- Collections
- Tags
- Logon settings
- Reconfigure Prisma Cloud
- Subject Alternative Names
- WildFire Settings
- Log Scrubbing
- Clustered-DB
- Permissions by feature
-
- Logging into Prisma Cloud
- Integrating with an IdP
- Integrate with Active Directory
- Integrate with OpenLDAP
- Integrate Prisma Cloud with Open ID Connect
- Integrate with Okta via SAML 2.0 federation
- Integrate Google G Suite via SAML 2.0 federation
- Integrate with Azure Active Directory via SAML 2.0 federation
- Integrate with PingFederate via SAML 2.0 federation
- Integrate with Windows Server 2016 & 2012r2 Active Directory Federation Services (ADFS) via SAML 2.0 federation
- Integrate Prisma Cloud with GitHub
- Integrate Prisma Cloud with OpenShift
- Non-default UPN suffixes
- Compute user roles
- Assign roles
- Credentials store
- Cloud accounts
-
- Prisma Cloud vulnerability feed
- Vulnerability Explorer
- Vulnerability management rules
- Search CVEs
- Scan reports
- Scanning procedure
- Customize image scanning
- Configure Registry Scans
-
- Scan Images in Sonatype Nexus Registry
- Scan images in Alibaba Cloud Container Registry
- Scan images in Amazon EC2 Container Registry (ECR)
- Scan images in Azure Container Registry (ACR)
- Scan images in Docker Registry v2 (including Docker Hub)
- 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 Artifactory Docker Registry
- Scan images in OpenShift integrated Docker registry
- Trigger registry scans with Webhooks
- Base images
- Configure VM image scanning
- Configure code repository scanning
- Agentless scanning
- Malware scanning
- Vulnerability risk tree
- Vulnerabilities Detection
- CVSS scoring
- Windows container image scanning
- Serverless function scanning
- VMware Tanzu blobstore scanning
- Scan App-Embedded workloads
- Troubleshoot vulnerability detection
-
- Compliance Explorer
- Enforce compliance checks
- CIS Benchmarks
- Prisma Cloud Labs compliance checks
- 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
- Cloud discovery
- OSS license management
- API
End-of-Life (EoL)
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
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 it:
- Looks for component and version details from OS package managers.
- Looks at 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 Console.
- 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 (Red Hat, Ubuntu, etc.), un-packaged software CVEs (see supported apps), and various open-source library CVEs (nodejs, python, etc.). Console is continually updated by the Intelligence Stream to provide the most up-to-date results.
- The correlation results are calculated, stored in DB, and displayed in the Console UI.
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, Defender might discover packages that are not in the original image, but installed sometime during the container lifetime (for example, if you exec’d into a running container, and ran wget … .jar).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.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.