Scanning procedure
Table of Contents
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.