Skip to main content

Who pays for scanning compute, and how much?

You do, directly, in your own scanning project’s billing; there’s no separate Plerion invoice for it. A typical VM scan costs a small amount of compute time. If you chose the Cloud NAT networking mode, that adds a standing per-region monthly charge plus data processing for as long as it’s provisioned, at Google’s Cloud NAT pricing. See Managing workload scanning for the full breakdown.

Can our security team inspect a scanner VM while it’s running?

Yes. Every scanner VM runs inside the scanning project in your own Google Cloud organization, so it’s visible in your own console like any other VM you own. Nothing about it is hidden or opaque.

What happens if a scanner VM is compromised?

An attacker who compromised a scanner VM would get the contents of the one scan disk it had attached, plus a token that can only upload scan results, nothing more. The scanner VM’s service account holds no IAM roles, so it can’t call any GCP API to read, modify, or pivot to anything else in your organization. See How scanning works for the full identity model.

Why does Plerion need compute.snapshots.delete?

To clean up after itself. Every snapshot Plerion creates for a scan is deleted once that scan finishes, and the permission is bound under an IAM condition that limits it to snapshots named with the plerion-scan- prefix; it can never delete a snapshot you created yourself. See Access and permissions for the exact grant.

How do we revoke Plerion’s access entirely?

Delete the workload identity pool (plerion) in your Plerion service project. This immediately ends all federated access for the whole GCP organization integration, including workload scanning. Plerion can no longer exchange tokens for your organization at all. To remove only the scanning project and its billed resources without revoking the rest of the integration, see Removing workload scanning entirely.

Does scanning touch the production disk or affect the running workload?

No. Scanning always works from a snapshot (a crash-consistent, point-in-time copy of the disk), never the disk attached to your running VM. Taking a snapshot doesn’t pause or measurably slow the workload.

Why is sensitive data scanning off by default?

Vulnerability and software bill of materials (SBOM) scanning are on by default because they carry no meaningful downside for most customers. Sensitive data scanning looks for secrets left on disk, which is a more sensitive class of result, so it’s opt-in: turn it on from the workload scanning step in the wizard or the integration’s edit dialog whenever you want it.

Is there a limit on how long a single scan can run?

Yes. Every scan is bounded by a hard 120-minute timeout. If a scan hasn’t finished by then, Plerion tears down its scanner VM, scan disk, and snapshot and marks the scan failed, rather than leaving anything running indefinitely.

What if a scan is interrupted partway through?

Plerion’s normal cleanup runs at the end of every scan, successful or not. A separate scheduled sweeper independently checks for anything left behind by an interrupted scan (matched by naming and labels) and removes it, so an interruption never leaves orphaned resources in your scanning project indefinitely.

Does workload scanning need a separate step to grant Plerion access to individual target projects?

No. The GCP organization integration already discovers every project in your organization automatically, and workload scanning reuses that discovery; there’s no equivalent of “linking a target account” to set up per project.

Why does one of my projects have findings but no vulnerabilities?

The project most likely has the Compute Engine API disabled, so there are no VM instances for Plerion to scan. Posture scanning is unaffected, which is why findings still appear. See Coverage.

Why is one of my projects missing from Plerion entirely?

If the project is Google-managed, Plerion never onboards it. See Projects Plerion does not scan.