Skip to main content
With GCP workload scanning, Plerion scans the software inside your Compute Engine instances, the container images behind your Cloud Run services and Cloud Functions, and the deployed source of your 1st gen functions. Plerion reports vulnerabilities, a software bill of materials (SBOM), and secrets. No agent is installed, and no disk contents, images, or source leave your Google Cloud organization. Workload scanning is a capability of the GCP organization integration. You turn it on for an organization you’ve already connected, and one re-run of the onboarding script or Terraform template creates everything it needs. In Plerion, the capability toggle is called Workload scanning. The badge on an integration reads Workload in the integrations list and CWPP (Cloud Workload Protection Platform) on the detail page, and the platform docs call the same feature workload security (CWPP).

What it scans

Each workload type is a separate toggle. Turn off the ones you don’t want scanned. See Coverage for what is excluded and why.

Scan types

  • Vulnerabilities: known Common Vulnerabilities and Exposures (CVEs) in operating system packages and application dependencies. On by default.
  • Software bill of materials (SBOM): the full package inventory of each workload. On by default.
  • Sensitive data: secrets such as API keys, tokens, and private keys left on disk, in an image, or in source. Off by default. Turn it on per integration.

What runs where

All scanning compute runs inside a scanning project that onboarding creates in your own organization, never in a Plerion-owned project. The scanning project holds the scanner VMs, the scan disks, the Cloud Run scan jobs, and the network they use. These resources are visible in your own console during a scan and billed to your account. Only scan results are sent to Plerion. Snapshots, scan disks, pulled images, and downloaded source are deleted when the scan finishes. See How scanning works for each flow step by step.

Terms used in these pages

  • Scanning project: the project onboarding creates for scanning compute. Its ID starts with plerion-scan- and it carries the label plerion-scan=true.
  • Tenant service account: the service account that onboarding created for Plerion in your Plerion service project. Plerion reaches it through Workload Identity Federation, with no key. It drives every GCP API call workload scanning makes.
  • Scanner VM: the short-lived Compute Engine instance that scans a disk. It runs under its own service account with no IAM roles.
  • Access command: the onboarding script command or Terraform apply that grants Plerion access. Plerion generates it for your current settings, and you re-run it whenever you change what Plerion is allowed to scan.

Next steps