Skip to main content
With GCP workload scanning, Plerion decides at the start of each scan run whether each asset can be scanned. Use this page to tell a coverage gap from a missing finding.

​
Supported workloads

Every workload type supports all three scan types: Vulnerabilities, Software bill of materials (SBOM), and Sensitive data.
GKE Standard node pools are ordinary Compute Engine instances, so Plerion scans each node the way it scans any instance. This is node-level coverage only. Pods, deployments, and other Kubernetes objects are covered by the Kubernetes integration. GKE Autopilot nodes don’t appear in the Compute Engine API, so they can’t be scanned.

​
What is skipped, and why

A skipped asset has no workload scan for that run. The reason isn’t shown in the dashboard. Plerion records it in its operational logs, which Plerion support can check for you. If an asset you expect to be scanned has no workload findings, check this table and Why does one of my projects have findings but no vulnerabilities? first. An asset Plerion tried to scan but couldn’t is different. A disk that wouldn’t mount, an image that couldn’t be pulled, or a source archive that was too large produces a scan record with a failed status and an error message on the project’s Workload scans tab. A run that an organization policy check blocked also shows there as failed, for the whole project.

​
CMEK-encrypted disks

Instances and custom images protected by a customer-managed encryption key (CMEK) are scanned. The snapshot keeps your key, but the scan disk Plerion creates in the scanning project uses Google-managed encryption for the minutes it exists, because Plerion creates it without your key. See Encrypted disks and images. PlerionAccess: Denied is a resource tag you apply to a project yourself (see Excluding a project’s custom images). If custom image scanning is on, it removes Plerion’s ability to read that project’s custom images. It doesn’t stop the project’s workloads from being scanned, and that includes instances with CMEK-encrypted disks. Plerion holds no access to your keys and never needs it. Your project’s Compute Engine service agent, which already holds your key because it created the encrypted disk, decrypts the snapshot when the scan disk is created. The scan disk itself uses Google-managed encryption, so no key is involved after that point. To stop scanning a project altogether, exclude it from the organization integration under Manage projects.
Excluding a project that is already onboarded deletes its project integration and all the findings and scan history Plerion holds for it, for both posture scanning and workload scanning. This can’t be undone, and Plerion asks you to confirm first.

​
Compute Engine custom images

Plerion scans every custom image a project owns, including images nothing has ever booted from. Whether an image is scanned depends on its state:
  • READY images are scanned. DEPRECATED images are scanned too, because they’re marked as on the way out but are still bootable.
  • Images that aren’t ready yet (PENDING, FAILED, DELETING) and images that can no longer be booted (OBSOLETE, DELETED) are skipped.
  • Images larger than 2048 GB are skipped.
  • An image Plerion can’t read is skipped. This happens when the access command hasn’t been re-run since you turned on the custom image type, when the grant has been removed, or when the image’s project is tagged PlerionAccess: Denied.
  • An image whose CMEK key Plerion can’t use is skipped without affecting the rest of the run.
Findings attach to the image (GCP::Compute::Image) and are independent of findings on instances booted from it. Image identity follows the image’s numeric ID, so rebuilding an image under the same name creates a new asset with its own finding history.

​
Compute Engine managed instance groups

Plerion samples one member per distinct boot image in the group, scans each sample like a standalone instance, and reports the merged result against the group. A group on one image produces one sample. A group mid-rolling-update produces one sample per image, each labeled with its image. Groups are capped at 10 samples per run. While managed instance group scanning is on, members of a scanned group aren’t scanned or reported as standalone instances. A group with no members has nothing to sample and is skipped for that run. Sampling has two limits:
  • A member patched after boot can differ from the sample. The sample reflects one member’s disk, not every member’s current state. Patch the image, not individual members, so future samples and every member built from them reflect the fix.
  • Only the sampled member’s boot disk is scanned. Data disks attached to group members aren’t covered while group scanning is on.

​
Cloud Functions (1st gen): dependency findings need pinned versions

Secrets scanning works on any deployed source. Dependency vulnerability findings need the function’s dependencies declared with exact versions or a lockfile in the deployed archive, because no scanner can tell which version of an unpinned dependency is deployed. A function without pinned dependencies still gets a completed scan, with secrets findings but no dependency findings.
gcloud functions deploy helps: its default .gcloudignore excludes node_modules but keeps package-lock.json, so most Node.js deployments qualify without changes. If you deploy with Terraform or a custom build, check that the lockfile or pinned manifest is in the uploaded archive.

​
Regions

Scan disks and scanner VMs are always created in the same region as the instance being scanned, and image and source scan jobs run in the region of the service or function. Cross-region scanning never happens. If you’ve limited scanning with the Workload regions setting, workloads outside those regions are skipped as out of scope. A custom image is a global resource, so Plerion scans it in the first region in that list. If the list is empty, it uses a region the project’s instance scans already use. Otherwise, it uses us-central1.

​
Next step