When scans run
Workload scanning has no schedule of its own. After each project’s posture scan completes, whether scheduled or started withScan now, Plerion starts a workload scan run for that project covering every enabled workload type. On the default daily schedule that means one workload scan per project per day.
Before enumerating anything, each run checks four organization policy constraints against the scanning project. A blocking result fails the run for that project rather than producing a silent empty result. The run shows as failed on the project’s Workload scans tab, and the constraint that blocked it is recorded in Plerion’s logs. See Prerequisites for the constraints and what to change.
Each run’s status (in progress, completed, failed, or timed out) appears on the project’s Workload scans tab. If any scanner VM in a run fails, the whole run is recorded as failed, even if other targets in it were scanned.
Compute Engine instances
1
Snapshot the boot disk
Plerion creates a snapshot of the instance’s boot disk in the project the instance lives in. A snapshot is taken out of band, so the running workload isn’t paused or slowed. The copy is crash-consistent.
2
Create a scan disk in the scanning project
Plerion creates a disk from the snapshot inside the scanning project, in the same region as the instance. The disk inherits the snapshot’s size.
3
Boot a scanner VM
A scanner VM boots in the scanning project and attaches the scan disk read-only. When your organization’s image policy allows it, the VM boots from Plerion’s pre-built public image (project
pln-public-artifacts, image family plerion-appliance), which already has the scanning toolchain installed. Otherwise, it boots Google’s public Ubuntu 22.04 image and installs a checksum-pinned scanning toolchain at startup. Scanning works the same way regardless of which image it boots from; the pre-built image only makes scans start faster. One scanner VM handles up to 10 scan targets in a run.4
Scan
The scanner VM mounts the disk and scans it for vulnerabilities, a software bill of materials (SBOM), and (if enabled) secrets. It makes no GCP API calls of its own.
5
Upload results
The scanner VM uploads results to Plerion over an authenticated, time-limited upload link that authorizes result uploads only. Findings leave your organization. Disk contents don’t.
6
Clean up
Plerion deletes the scan disk, the scanner VM, and the snapshot.
RUNNING or TERMINATED (stopped) state are scanned, and only their boot disk is scanned.
Compute Engine custom images
A custom image has no running disk to snapshot, so Plerion creates the scan disk directly from the image in the scanning project and skips the snapshot step. Everything else matches the instance flow above: same scanner VM, same read-only attach, same upload, and cleanup deletes the disk and VM. Nothing is created in the project that owns the image. Plerion scans every custom image a project owns that is in theREADY state, whether or not anything has booted from it, so a golden image is checked before your fleet is built from it. Findings attach to the image itself and are kept separate from any instance booted from it, because an instance can diverge from its image the moment it is patched.
A custom image is a global resource, so it has no region to match. Plerion runs the scan in the first region listed in your Workload regions setting. If that setting is empty, it uses a region the same project’s instance scans already use. Otherwise, it uses us-central1.
Compute Engine managed instance groups
A managed instance group can run hundreds of identical members, so Plerion samples instead of scanning each one.1
List the group's members
Plerion reads the group’s authoritative member list from the Compute Engine API and drops members that are being deleted or don’t exist yet.
2
Skip GKE node pools
A group whose members carry the
goog-gke-node label belongs to a GKE node pool. Plerion skips it at the group level. Its nodes stay covered as ordinary Compute Engine instances.3
Group members by boot image
Plerion reads each member’s boot disk to find the image it was created from and groups members that share an image. A group mid-rolling-update, running two image versions, produces two groups. Members whose boot disk has no recorded source image form one extra group.
4
Pick one sample per image
From each image group Plerion picks one member, preferring a running member over a stopped one and breaking ties by name, so the same unchanged group samples the same member every run. A group is capped at 10 samples per run.
5
Scan each sample and merge
Each sample goes through the instance flow above. Plerion merges the samples into one scan record for the group, labels each sample’s findings with the image it came from, and attaches the findings to the group.
Cloud Run services and Cloud Functions (2nd gen)
A Cloud Run service runs a container image, and a 2nd gen function is a Cloud Run service underneath, so both are scanned the same way. The image for a 2nd gen function is the one Google built when it deployed the function, stored in thegcf-artifacts repository in your project.
1
Resolve the serving image digest
Plerion reads the service’s serving revisions (the latest ready revision and any revision receiving traffic) and takes the exact image digest each one runs. The revision already records the digest, so no registry lookup is needed and a mutable tag such as
:latest is never trusted. Every container in the revision, including sidecars, is scanned.2
Run a Cloud Run job in the scanning project
Plerion starts an execution of the standing image scan job for that region (
plerion-scan-artifact-<region>), passing the digest as a per-execution override. The job runs as the artifact-scanner service account, with 1 vCPU and 2 GiB of memory, and fetches its own registry token from the metadata server at runtime. No credential is written into the job definition.3
Pull and scan
The job pulls the image from your Artifact Registry and scans it for vulnerabilities, an SBOM, and (if enabled) secrets.
4
Upload results and delete the execution
The job uploads results over the same kind of time-limited upload link the scanner VM uses, bound to the digest it was launched to scan. Plerion then deletes the execution.
Cloud Functions (1st gen)
A 1st gen function is deployed from a source archive, not a container image, so Plerion downloads that source and scans it.1
Ask Google Cloud for a download link
Plerion requests a short-lived download link for the function’s currently deployed source. The link is never written into the job definition, the execution record, or Plerion’s logs.
2
Download and unpack in a Cloud Run job
An execution of the standing source scan job for that region (
plerion-scan-source-<region>) downloads the archive and unpacks it inside the job’s container, which has no persistent disk. The job runs as the source-scanner service account, with 1 vCPU and 4 GiB of memory. Archives over 100 MB compressed or 500 MB unpacked are skipped.3
Scan
The job scans the source for dependency vulnerabilities, an SBOM, and (if enabled) secrets. Findings attach to the same Cloud Functions asset a 2nd gen function’s scan would, so both generations appear in the same place.
4
Upload results and delete the execution
The job uploads results over a time-limited upload link bound to the function and source version it scanned. Plerion then deletes the execution.
The identities involved
The three scanner identities are separate, so compromising one grants none of the others’ access. See Access and permissions for every permission.
Encrypted disks and images
- Customer-managed encryption keys (CMEK): the snapshot keeps the source disk’s key, but the scan disk Plerion creates in the scanning project uses Google-managed encryption. Plerion creates it without your key. For the minutes the scan disk exists, Google’s key protects it rather than yours. It is deleted at the end of the scan. The same applies to a scan disk created from a CMEK-protected custom image.
- Customer-supplied encryption keys (CSEK): Plerion has no way to supply your key, so CSEK-encrypted disks are skipped.
Cleanup and the sweeper
Every resource Plerion creates for a scan is labeledowner=plerion, plus the tenant, integration, and execution that own it. Snapshots, scan disks, and scanner VMs are also named with a plerion-scan- prefix. Cleanup runs at the end of every scan, whether it succeeded or not. A separate sweeper runs every hour in the scanning project and removes any Plerion-labeled resource older than 24 hours, so an interrupted scan can’t leave resources behind for long. Because the scanning project is yours, you can also delete any leftover resource yourself.