Skip to main content
With workload scanning, Plerion scans the software running inside your Compute Engine VM instances for vulnerabilities, software bill of materials (SBOM), and sensitive data, without an agent and without any of your data leaving your Google Cloud organization. It’s a capability of the GCP organization integration: turn it on for an organization you’ve already connected, and Plerion sets up everything it needs with one script re-run.

What it scans

v1 covers one workload type: Compute Engine VM instances. Plerion snapshots each instance’s disk, mounts a scan disk built from that snapshot, and runs the scan against that copy, never the running workload itself. Cloud Functions, Cloud Run, and managed instance groups (MIGs) are not yet supported; see Coverage for the full picture, including asset types that are permanently out of scope. Three scan types are available:
  • Vulnerability scanning: known Common Vulnerabilities and Exposures (CVEs) in OS packages and software dependencies.
  • SBOM (software bill of materials): the full package inventory, generated in CycloneDX format.
  • Sensitive data: secrets such as API keys, tokens, and private keys left on disk.
Vulnerability and SBOM scanning are on by default; sensitive data scanning is off by default and can be turned on per integration.

What runs where

All scanning compute runs inside a scanning project that onboarding creates in your own Google Cloud organization, not in a Plerion-owned project. Concretely:
  • Plerion snapshots a target VM’s disk in place, in the project where the VM lives.
  • It creates a scan disk from that snapshot in the scanning project, in the same region.
  • It boots a short-lived scanner VM in the scanning project, attaches the scan disk read-only, and scans it.
  • Scan results are uploaded to Plerion. The snapshot, scan disk, and scanner VM are deleted once the scan finishes.
Nothing about the scan is opaque: the scanning project is yours, its billing shows exactly what scanning costs, and any scanner VM Plerion creates is visible in your own console while it runs. See How scanning works for the full mechanics, including the identity model and cleanup guarantees.

What leaves your organization

Only scan results (findings JSON) are sent to Plerion. Disk contents, snapshots, and scan disks never leave your Google Cloud organization. This is the core difference from a Plerion-managed scanning model, where scanning compute runs in Plerion’s own cloud: here, you can see and audit every resource Plerion creates, because it’s created inside your own scanning project.

What you don’t have to do

Unlike Plerion’s AWS service account, GCP workload scanning needs no separate “linking” step for target projects. The GCP organization integration already discovers every project in your organization automatically, and workload scanning reuses that same discovery: any project the organization integration finds is a candidate for workload scanning, with no per-project account to connect.

Next steps